Re: hot_standby_feedback default and docs

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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:26:43
Message-ID: 5602D2C3.5030003@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-09-23 16:37:15 Re: Parallel Seq Scan
Previous Message Robert Haas 2015-09-23 16:17:46 Re: unclear about row-level security USING vs. CHECK