On Wed, Mar 16, 2011 at 4:41 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
