On Wed, Mar 16, 2011 at 4:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> > Another problem here is that we are defaulting to hot_standby=off and
>> > pause_at_recovery_target=on. So AIUI, with this patch, if someone
>> > sets a recovery target without making any other changes to the
>> > configuration, their database won't start up. That seems poor.
>>
>> We should flip the default value of pause_at_recovery_target?
>
> No, we shouldn't. Robert's comments are wrong and he shouldn't post such
> things without testing them or reading the code.
Did you miss the part where I said "with this patch"? Because my
description of what happens with Fujii-san's patch applied does in
fact match the behavior of the code he wrote. It doesn't match the
current behavior, nor was it intended to describe the current
behavior.
>> > Even without the FATAL error, this whole pause_at_recovery_target
>> > thing is a little weird. If someone sets a recovery target without
>> > making any other configuration changes, and Hot Standby is not
>> > enabled, then we will enter normal running, but if Hot Standby *is*
>> > enabled, then we'll replay to that point and pause recovery. That
>> > seems a bit confusing.
>>
>> That's because there is no way to resume recovery which was
>> paused by pause_at_recovery_target when hot standby is disabled,
>> i.e., in that case we cannot call pg_xlog_replay_resume() to resume
>> the recovery.
>>
>> How should recovery work when pause_at_recovery_target is
>> enabled but hot standby is disabled? We have three choices:
>>
>> 1. Forbit those settings, i.e., throw FATAL error. Tom dislikes this
>> idea.
>> 2. Ignore pause_at_recovery_target. When recovery reaches the
>> target, it ends without pausing, and then the server gets into
>> normal processing mode. This would be unexpected behavior
>> from DBA's point of view because he or she expects that
>> recovery is paused at the target. To retry recovery, he or she
>> needs to restore the backup again.
>> 3. Pause recovery even if hot standby is disabled. Since there
>> is no way to resume recovery, recovery would pause until
>> shutdown is requested.
>>
>> For me, #1 looks like the most harmless in them. But, better
>> ideas? Votes?
>
> (2) is how it works now.
>
> (3) doesn't sound very sensible. Why would that be better than (2)
>
> There's lots of ways to misconfigure things, so I'm not too concerned
> about this minor point.
I agree that (3) is not very sensible. I think there's a reasonable
debate to be had about whether (1) or (2) is better. Like you, I
prefer #2 (the current behavior) to #1 (the proposed patch); but for
my money it would be a little less confusing if the default were
pause_at_recovery_target=false.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
