Re: hot_standby_feedback default and docs

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hot_standby_feedback default and docs
Date: 2015-09-23 16:43:54
Message-ID: CA+TgmoYqxrMTkPbD04QXgoan7dgJy+RaqZJO78A__37N5sz9MQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 23, 2015 at 12:26 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 9/23/15 10:44 AM, Robert Haas wrote:
>> On Tue, Sep 22, 2015 at 3:35 PM, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-09-23 16:45:14 Re: TEXT vs VARCHAR join qual push down diffrence, bug or expected?
Previous Message Peter Eisentraut 2015-09-23 16:37:37 Re: unclear about row-level security USING vs. CHECK