On Fri, Mar 18, 2011 at 1:17 AM, Robert Haas <robertmh...@gmail.com> wrote: >> Sorry, I've not been able to understand the point well yet. We should >> just use elog(ERROR) instead? But since ERROR in startup process >> is treated as FATAL, I'm not sure whether it's worth using ERROR >> instead. Or you meant another things? > > Yeah, I think he's saying that an ERROR in the startup process is > better than a FATAL, even though the effect is the same.
We've already been using FATAL all over the recovery code. We should s/FATAL/ERROR/g there (at least readRecoveryCommandFile)? > On the substantive issue, I don't think we have any consensus that > forbidding this combination of parameters is the right thing to do > anyway. Both Simon and I voted against that, and Tom's point has to > do only with style. Similarly, I voted for flipping the default for > pause_at_recovery_target to off, rather than on, but no one else has > bought into that suggestion either. Unless we get some more votes in > favor of doing one of those things, I think we should focus on the > actual must-fix issue here, which is properly documenting the way it > works now (i.e. adding the parameter to recovery.conf.sample with > appropriate documentation of the current behavior). I agree to flip the default to false, whether we forbid that combination of settings. > One thing I'm not quite clear on is what happens if we reach the > recovery target before we reach consistency. i.e. create restore > point, flush xlog, abnormal shutdown, try to recover to named restore > point. Is there any possibility that we can end up paused before Hot > Standby has actually started up. Because that would be fairly useless > and annoying. Good catch! In that case, the same situation as (3) would happen. I think that recovery should ignore pause_at_recovery_target until it reaches consistent point. If we do so, when recovery target is ahead of consistent point, recovery just ends in inconsistent point and throws FATAL error. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
