Oops, sorry. Permissions fixed.
---
Janardhan wrote:
> The file "ftp://candle.pha.pa.us/pub/postgresql/PITR_20020822_02.gz";
> do not
> have read permissions to copy. please provide the read permissions to copy.
>
> Reg
The file "ftp://candle.pha.pa.us/pub/postgresql/PITR_20020822_02.gz"
do not
have read permissions to copy. please provide the read permissions to
copy.
Regards
jana
Patrick Macdonald wrote:
Bruce Momjian wrote:
I wanted to outline some of the big items we are loo
Is this it ?
Output of cygwin
Administrator@ABC-NQ0MBUYZ4EH ~
$ pwd
/home/Administrator
Administrator@ABC-NQ0MBUYZ4EH ~
$ cd ..
Administrator@ABC-NQ0MBUYZ4EH /home
$ cd ..
Administrator@ABC-NQ0MBUYZ4EH /
$ ls -l
total 890
drwxrwxrwx+ 3 Administ None 200704 Dec 17 01:44 bin
-rwx---
On Tue, 17 Dec 2002, Christopher Kings-Lynne wrote:
> Hi guys,
>
> Just a thought - do we explicitly wipe password strings from RAM after using
> them?
>
> I just read an article (by MS in fact) that illustrates a cute problem.
> Imagine you memset the password to zeros after using it. There is
Hi guys,
Just a thought - do we explicitly wipe password strings from RAM after using
them?
I just read an article (by MS in fact) that illustrates a cute problem.
Imagine you memset the password to zeros after using it. There is a good
chance that the compiler will simply remove the memset from
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> Oh, yeah I have no doubt of that. I was thinking more along the lines of
> when a transaction ends it throws a background "vacuum table1;vacuum
> table2;vacuum tablen" command into some kind of vacuuming hopper.
Actually, the plans I liked best for
No :)
Magnus
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Mon, 16 Dec 2002, Marc G. Fournier wrote:
> On Mon, 16 Dec 2002, scott.marlowe wrote:
>
> > On Mon, 16 Dec 2002, Tom Lane wrote:
> >
> > > Josh Berkus <[EMAIL PROTECTED]> writes:
> > > > How hard would it be to add a "WITH (VACUUM)" option to UPDATE and DELETE
> > > > queries? This option wo
On Mon, 16 Dec 2002, scott.marlowe wrote:
> On Mon, 16 Dec 2002, Tom Lane wrote:
>
> > Josh Berkus <[EMAIL PROTECTED]> writes:
> > > How hard would it be to add a "WITH (VACUUM)" option to UPDATE and DELETE
> > > queries? This option would cause the regular vacuum activity -- purging the
> > > d
Robert Treat writes:
> I've never been one for actively going against the sql standards (which
> this case would seem to do) so if it is done lets make sure we add
> documentation to point out that we aren't compliant on this issue.
This could be a reasonable place to hook in the "SQL flagger"
(n
Steve King <[EMAIL PROTECTED]> writes:
> Files output from pg_filedump are below,
> I have two tables with duplicate oids and these are the pg_filedumps for
> them.
Hmm. You seem to have a rather unusual usage pattern for these tables
--- it looks like there are *lots* of failed (rolled back) upd
On Mon, 16 Dec 2002, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > How hard would it be to add a "WITH (VACUUM)" option to UPDATE and DELETE
> > queries? This option would cause the regular vacuum activity -- purging the
> > dead tuple and its index references -- to be done imme
Josh Berkus <[EMAIL PROTECTED]> writes:
> How hard would it be to add a "WITH (VACUUM)" option to UPDATE and DELETE
> queries? This option would cause the regular vacuum activity -- purging the
> dead tuple and its index references -- to be done immediately, as part of the
> statement, instead o
Hello everybody,
Some days ago was released pgaccess 0.98.8 This release marks the end
first phase of the work of the Redux team that came together in April
this year - Chris, Bartus, Brett, and some others.
After the release was renewed the practice weekly releases to be made.
They have the n
Marc,
> > Easy? Hard? Insane? What do you think?
>
> Just curious, but wouldn't it be just as simple to issue a VACUUM call
> right after the UPDATE/DELETE?
Well, you can't do that as part of a transaction or procedure, whereas
Hmmm. Couldn't do "with vacuum" as part of a transaction,
On Mon, 16 Dec 2002, Josh Berkus wrote:
> Tom, Folks:
>
> Joe and I were discussing your recent discussion about the costs of VACUUM and
> tuple maintainence, and I had an interesting idea.
>
> How hard would it be to add a "WITH (VACUUM)" option to UPDATE and DELETE
> queries? This option would
Tom, Folks:
Joe and I were discussing your recent discussion about the costs of VACUUM and
tuple maintainence, and I had an interesting idea.
How hard would it be to add a "WITH (VACUUM)" option to UPDATE and DELETE
queries? This option would cause the regular vacuum activity -- purging the
On Mon, Dec 16, 2002 at 05:41:06PM +0100, Jeroen T. Vermeulen wrote:
>
> Speaking of which, what if user relies on sizeof(PGnotify::relname)?
^
code
Jeroen
---(end of broadcast)---
Patrick Macdonald wrote:
> > OK, I just talked to Patrick on the phone, and he says Neil Conway is
> > working on merging the code into 7.3, and adding missing pieces like
> > logging table creation. So, it seems PITR is moving forward.
>
> Well, sort of. I stated that Neil was already working o
Bruce Momjian wrote:
>
> Patrick Macdonald wrote:
> > Bruce Momjian wrote:
> > >
> > > I wanted to outline some of the big items we are looking at for 7.4:
> > >
> > > [snip]
> > >
> > > Point-In-Time Recovery (PITR)
> > >
> > > J. R. Nield did a PITR patch late in 7.3 development, and Pat
On Mon, 2002-12-16 at 13:38, Bruce Momjian wrote:
> OK, I just talked to Patrick on the phone, and he says Neil Conway is
> working on merging the code into 7.3, and adding missing pieces like
> logging table creation. So, it seems PITR is moving forward. Neil, can
> you comment on where you are
Patrick Macdonald wrote:
> Bruce Momjian wrote:
> >
> > I wanted to outline some of the big items we are looking at for 7.4:
> >
> > [snip]
> >
> > Point-In-Time Recovery (PITR)
> >
> > J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> > MacDonald from Red Hat i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> ppage = BufferGetPage(pbuf);
> pop = (BTPageOpaque) PageGetSpecialPointer(ppage);
> max = PageGetMaxOffsetNumber(pop);
I believe you want PageGetMaxOffsetNumber(ppage) ...
regards, tom lane
--
Tom Lane wrote:
>
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Fri, Dec 13, 2002 at 09:43:19AM -0500, Tom Lane wrote:
> >> Actually, if you don't mind grabbing a copy of pg_filedump --- see
> >> http://sources.redhat.com/rhdb/tools.html
>
> > Has this been updated for 7.3? Last time I loo
Bruce Momjian wrote:
>
> I wanted to outline some of the big items we are looking at for 7.4:
>
> [snip]
>
> Point-In-Time Recovery (PITR)
>
> J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> MacDonald from Red Hat is working on merging it into CVS and
>
On Mon, Dec 16, 2002 at 11:01:00AM -0500, Bruce Momjian wrote:
>
> New question --- didn't we change the externally visible PGNotify
> structure in libpq-fe.h in 7.3, and as returned by PQnotifies:
Speaking of which, what if user relies on sizeof(PGnotify::relname)?
That code will recompile witho
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > meaning if ecpg references PGnotify, should it have a new major number
> > too,
>
> No, because PGnotify is *not part of ecpg's API*.
>
> The ecpg library, when compiled, will show a dependency on the new major
> number for libpq. T
Bruce Momjian <[EMAIL PROTECTED]> writes:
> meaning if ecpg references PGnotify, should it have a new major number
> too,
No, because PGnotify is *not part of ecpg's API*.
The ecpg library, when compiled, will show a dependency on the new major
number for libpq. That does not mean that applicati
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >> Do I need to increment the other interfaces that
> >> _use_ libpq, like ecpg?
>
> > If and only if the libpq API is part of their documented API. For ecpg I
> > think this is not the case, but for libpq+
Shridhar Daithankar wrote:
> On Monday 16 December 2002 08:07 pm, you wrote:
> > On Mon, 2002-12-16 at 08:20, Shridhar Daithankar wrote:
> > > I don't know about WAL numbering but AFAIU, it increments and old files
> > > are removed once there are enough WAL files as specified in
> > > posgresql.co
Steve King <[EMAIL PROTECTED]> writes:
> I've now got a copy of pg_filedump and compiled it, can you tell me the
> command line parameters to pass it (and the file that I must process) so I
> can give you exactly what you require.
I'd recommend
pg_filedump -f -i -R
where is whatever p
On Monday 16 December 2002 08:07 pm, you wrote:
> On Mon, 2002-12-16 at 08:20, Shridhar Daithankar wrote:
> > I don't know about WAL numbering but AFAIU, it increments and old files
> > are removed once there are enough WAL files as specified in
> > posgresql.conf. IIRC there are some perl based re
On Mon, 2002-12-16 at 08:20, Shridhar Daithankar wrote:
> On Monday 16 December 2002 07:43 pm, you wrote:
> > Consider that on the slave which is now the active server (master dead),
> > it's possible that the slave's PITR's will be recycled before the master
> > can come back up. As such, unless
On Fri, 2002-12-13 at 19:27, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Should we remove this error check, thereby effectively making
> > zero-column tables first-class citizens?
>
> Yes.
>
I've never been one for actively going against the sql standards (which
this case would seem to do)
On Monday 16 December 2002 07:43 pm, you wrote:
> Consider that on the slave which is now the active server (master dead),
> it's possible that the slave's PITR's will be recycled before the master
> can come back up. As such, unless there is a, an archival process for
> PITR or b, a method of str
Hi,
I have a trigger in my database that checks to see if there is another
record in the table, and when there is if the type is correct. (if the
first one is of type "parent", the other has to be of type "child").
When updating these records in a transaction, the trigger only works when
I mak
I must of miscommunicated here as you're describing PITR replication.
I'm asking about a master failing and the slaving picking up. Now, some
n-time later, how do you recover your master system to be back in sync
with the slave. Obviously, I'm assuming some level of manual recovery.
I'm wonderi
On Monday 16 December 2002 07:26 pm, you wrote:
> I'm curious, what would be the recovery strategy for PITR master-slave
> replication should the master fail (assuming hot fail over/backup)? A
> simple dump/restore? Are there/is there any facilities in PorstgreSQL
> for PITR archival which preven
On Fri, 2002-12-13 at 04:53, Hannu Krosing wrote:
> On Fri, 2002-12-13 at 06:22, Bruce Momjian wrote:
> > I wanted to outline some of the big items we are looking at for 7.4:
> > Point-In-Time Recovery (PITR)
> >
> > J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> > Mac
I've now got a copy of pg_filedump and compiled it, can you tell me the
command line parameters to pass it (and the file that I must process) so I
can give you exactly what you require.
Thanks
Steve
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: 13 December 2002 14:43
On Sun, 15 Dec 2002 23:49:57 -0300, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
>PageGetMaxOffsetNumber (the upper bound) returns a consistent value
>that's far too high (4294967291, 0xFFFB)
Alvaro, maybe this comment from bufpage.h can shed some light on it?
/*
* PageGetMaxOffsetNumber
* Re
42 matches
Mail list logo
