Re: [HACKERS] hot_standby_feedback default and docs

[Robert Haas]

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

Re: [HACKERS] hot_standby_feedback default and docs

[Peter Eisentraut]

On 9/23/15 10:44 AM, Robert Haas wrote:
> On Tue, Sep 22, 2015 at 3:35 PM, Peter Eisentraut  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.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] hot_standby_feedback default and docs

[Robert Haas]

On Tue, Sep 22, 2015 at 3:35 PM, Peter Eisentraut  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.

-- 
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

Re: [HACKERS] hot_standby_feedback default and docs

[Peter Eisentraut]

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.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] hot_standby_feedback default and docs

[Simon Riggs]

On 16 September 2015 at 15:37, Peter Eisentraut  wrote:

> On 9/16/15 1:12 PM, Michael Paquier wrote:
> > On Wed, Sep 16, 2015 at 7:51 AM, Peter Eisentraut 
> wrote:
> >> Also, the documentation claims that this parameter requires a postmaster
> >> restart, but the code thinks it's SIGHUP.  Which one is wrong?
> >
> > To which part of the documentation are you referring to? The parameter
> > is SIGHUP as I recall and aimed to be such.
>
>
> http://www.postgresql.org/docs/9.5/static/runtime-config-replication.html#GUC-HOT-STANDBY-FEEDBACK
>
>
Those docs say "This parameter can only be set in the postgresql.conf file
or on the server command line."

When a restart is required we say "This parameter can only be set at server
start."
e.g. hot_standby

So the docs look correct.


IMHO the default is the best one at the current time. See
recovery_min_apply_delay.
I've got some changes that I'd like to make once Kevin's snapshot too old
patch has gone thru that might change that.

-- 
Simon Riggshttp://www.2ndQuadrant.com/

PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] hot_standby_feedback default and docs

[Peter Eisentraut]

On 9/16/15 1:12 PM, Michael Paquier wrote:
> On Wed, Sep 16, 2015 at 7:51 AM, Peter Eisentraut  wrote:
>> Also, the documentation claims that this parameter requires a postmaster
>> restart, but the code thinks it's SIGHUP.  Which one is wrong?
> 
> To which part of the documentation are you referring to? The parameter
> is SIGHUP as I recall and aimed to be such.

http://www.postgresql.org/docs/9.5/static/runtime-config-replication.html#GUC-HOT-STANDBY-FEEDBACK


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] hot_standby_feedback default and docs

[Michael Paquier]

On Wed, Sep 16, 2015 at 7:51 AM, Peter Eisentraut  wrote:
> Also, the documentation claims that this parameter requires a postmaster
> restart, but the code thinks it's SIGHUP.  Which one is wrong?

To which part of the documentation are you referring to? The parameter
is SIGHUP as I recall and aimed to be such.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers