Re: WAL recovery question - 0000001.history

Hi Tom,Thanks for this.  Do you know why Postgres was asking for
00000001.history?  Surely it would know by the presence of the
backup_label file, and its contents that it needs to go straight for the
xxxxxx.backup file, which should exist?What other files is Postgres
likely to be asked for during a PITR restore?  Obviously log files that
don't exist do need to be waited for - hence the need for this script. 
If you want PG to come back up without the log it's waiting on, you just set
the flag file and it'll come up at the next interval.So far all I can see
that's problematic is this 0000001.history file which I don't know what it is,
and it'll never exist because it was never generated on the live.The other
thing I'm building in as well, is a file-size check, so when shipping logs
directly from another server (e.g. live to standby), when the script finds a
log, it will read the file size, wait 5 seconds, then read it again - if the 2
values differ, the log is still being transferred, so it will wait for another
interval and check again before doing anything - preventing itself from
pinching the log while it's still being transferred, and causing errors when
PG tries to read it.This will also remove as much human intervention as
possible from the whole process.AndyTom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:> "Andy Shellam" <andy(dot)shellam(at)mailnetwork(dot)co(dot)uk>
writes:> > Basically I've taken a dump of my live database directory
(between> > pg_start_backup and pg_stop_backup) calls - shipped this to
my standby, set> > up a recovery.conf file (which calls the rolling-WAL
script). This script> > is designed to wait until the log file arrives,
or a flag file is set to> > return code 1 to postgres.> > >
However as soon as the recovery starts, the script is waiting for a file>
> called 00000001.history, which will never arrive because it was never>
> generated on the live box since the base backup was taken.> > This
is not a workable approach: your recovery script *will* be asked> for files
that do not exist, and waiting for them to be supplied is not> always the
right answer. Supplying an empty file instead is definitely> the wrong
answer.> > You might be able to make it work by conditionalizing the
behavior on> the format of the name being asked for.> > regards, tom
lane> > ---------------------------(end of
broadcast)---------------------------> TIP 4: Have you searched our list
archives?> > http://archives.postgresql.org> >
!DSPAM:14,445239a233692110055341!> > >
__________________________________________________________
The mail network cannot accept liability for the content
of this e-mail. It is recommended you scan it for viruses
immediately upon receipt.

Is this e-mail spam? Report it to abuse(at)mailnetwork(dot)co(dot)uk