On 07.05.2011 16:48, Robert Haas wrote:
I was able to reproduce something very like this in unpatched master, just by letting recovery pause at a named restore point, and then resuming it.LOG: recovery stopping at restore point "stop", time 2011-05-07 09:28:01.652958-04 LOG: recovery has paused HINT: Execute pg_xlog_replay_resume() to continue. (at this point I did pg_xlog_replay_resume()) LOG: redo done at 0/5000020 PANIC: wal receiver still active LOG: startup process (PID 38762) was terminated by signal 6: Abort trap LOG: terminating any other active server processes I'm thinking that this code is wrong: if (recoveryPauseAtTarget&& standbyState == STANDBY_SNAPSHOT_READY) { SetRecoveryPause(true); recoveryPausesHere(); } reachedStopPoint = true; /* see below */ recoveryContinue = false; I think that recoveryContinue = false assignment should not happen if we decide to pause. That is, we should say if (recoveryPauseAtTarget && standbyState == STANDBY_SNAPSHOT_READY) { same as now } else recoveryContinue = false.
No, recovery stops at that point whether or not you pause. Resuming after stopping at the recovery target doesn't mean that you resume recovery, it means that you resume to end recovery and start up the server (see the 2nd to last paragraph at http://www.postgresql.org/docs/9.1/static/recovery-target-settings.html). It would probably be more useful to allow a new stopping target to be set and continue recovery, but the current pause/resume functions don't allow that.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
