From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
Cc: | Manfred Spraul <manfred(at)colorfullife(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: hot spare / log shipping work on |
Date: | 2004-08-13 20:32:59 |
Message-ID: | 26753.1092429179@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gaetano Mendola <mendola(at)bigfoot(dot)com> writes:
> I'm facing however to the following problems:
> 1) Discovery the actual WAL file
> I'm supposing is the last modified file inside the
> pg_xlog directory. If this is not the good method
> may I know how I can know it ?
While that theoretically will work, it leaves a bad taste in my mouth.
I have been thinking of proposing that we add a "pg_current_wal_file()"
function, or some such name, to return the name of the active WAL file.
> 2) During the recovery phase postmaster ask me for file that will never be
> there like: 00000001.history.
> Actualy if the file does not exist and contain the string history
> instead to wait for him I exit with 1 exit code
I think you can reasonably assume that .history files won't show up
on-the-fly, since they are only created during a PITR recovery operation
on the master. It's not clear how this whole thing should track such an
operation on the master anyway :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2004-08-13 21:41:48 | Calling PL functions with named parameters |
Previous Message | Gaetano Mendola | 2004-08-13 19:45:36 | Re: hot spare / log shipping work on |