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