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.
Andy
Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
> "Andy Shellam" <andy.shellam@xxxxxxxxxxxxxxxxx> 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!
>
>
>
