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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
