On Wed, Sep 23, 2015 at 12:26 PM, Peter Eisentraut <pete...@gmx.net> wrote: > On 9/23/15 10:44 AM, Robert Haas wrote: >> On Tue, Sep 22, 2015 at 3:35 PM, Peter Eisentraut <pete...@gmx.net> wrote: >>> On 9/16/15 5:52 PM, Simon Riggs wrote: >>>> IMHO the default is the best one at the current time. >>>> See recovery_min_apply_delay. >>> >>> The applications of recovery_min_apply_delay are likely to be varied and >>> specific, so there might not be a general answer to this, but wouldn't >>> you want hot_standby_feedback on with it? Because the longer you wait >>> on the standby, the more likely it is that the primary will clean stuff >>> away. >> >> If min_recovery_apply_delay was set to 1 hour, and if the standby had >> hot standby feedback turned on, wouldn't that mean that the master had >> to not do any HOT pruning or vacuuming of tuples until they had been >> dead for at least an hour? That seems like it would be bad. > > I suppose that's what would happen, and it might be bad, but the > alternative is that the primary might vacuum away everything and you > won't be able to make much use of the delayed standby. > > I'm not clear on the intended usage scenarios for > recovery_min_apply_delay, but the ramifications don't appear to be well > explained anywhere.
Well, the alternative to enabling hot standby feedback is that the query might get cancelled. But it might also NOT get cancelled. I mean, if recovery_min_apply_delay is set to an hour, and the query runs for a minute, you're only going to get a cancel if some data that is needed got pruned during the correponding minute an hour earlier on the master. And even then you can avoid a cancel by setting max.*standby_delay to at least 61 seconds, which is more likely to be acceptable for a standby that intentionally lags the master. But even if you don't do that, it's not as if every query you issue is going to get cancelled. -- 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
