Re: BUG #4137: Postgres drives pg_standby %r param to delete WAL file before processing

On Fri, 2008-05-02 at 18:11 +0000, Wojciech Strzalka wrote:

> I've discovered problem with WAL recovery on standby server.

Thanks for reporting it.

> I start copy database to the second
> machine which takes me 30 minutes.

> The output from pg_standby:
> ------------------------------------
> Trigger file             : /tmp/pgsql.promote_trigger.5432
> Waiting for WAL file     : 00000001.history
> WAL file path            : /var/lib/pgsql/incoming_wal/
> 00000001.history
> Restoring to...          : pg_xlog/RECOVERYHISTORY
> Sleep interval           : 5 seconds
> Max wait interval        : 0 forever
> Command for restore      : ln -s -f "/var/lib/pgsql/incoming_wal/
> 00000001.history" "pg_xlog/RECOVERYHISTORY"

> Keep archive history     : 0000000100000001000000DB and later
...................................................^^
> running restore          : OK

Looks like the first message gives and incorrect archive cut-off point.

My guess is that its picking up a checkpoint that happens during backup
as the starting point for the cutoff, which is incorrect. My guess at a
fix is that we need to make sure that the %r value is always less than
or equal to the %f value. Sounds like a good safeguard even if that
doesn't fix this specific bug.

I'll check and see if I can recreate it, then patch. Won't be tonight
though.

If I'm right, then removing the %r value from the restore_command should
make this work correctly as a workaround. Please let me know either way.

--
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com