From: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Greg Clough <greg(at)gclough(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while |
Date: | 2016-03-02 22:55:29 |
Message-ID: | 56D76F61.5060504@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 02/01/2016 13:14, Michael Paquier wrote:
> On Thu, Dec 31, 2015 at 8:13 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Thu, Dec 31, 2015 at 12:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>>> On 2015-12-26 22:45:57 +0900, Michael Paquier wrote:
>>>>> Depending on the use cases, it may be interesting to have a switch
>>>>> allowing to not apply the delay should a consistent point not be
>>>>> reached though...
>>>
>>>> Is there actually any case where it's interesting to delay in that
>>>> scenario? I mean that really can only happen if you changed the
>>>> configuration to a different delay, or your clock offset
>>>> changed. Otherwise we should always reach the consistent point before
>>>> the delay plays a role. I'm tempted to simply only check for delay when
>>>> consistent.
>>>
>>> The argument for having a delay at all is to allow backing up to some
>>> earlier point in the master's history; but a slave that is not yet
>>> consistent cannot provide any rollback/recovery option. The slave is
>>> completely useless for any purpose until it reaches consistency, so
>>> it might as well do that as fast as possible, and then sit on the
>>> next WAL record until the delay is met. +1 for no delay at all when
>>> not consistent.
>>
>> OK, I don't mind doing so if you guys think that's more adapted. Based
>> on reading the code, it seems obvious though that this was made so as
>> a delay is taken into account even before the node is consistent.
>
> Changing my mind after more thoughts on the matter, it seems indeed
> that it would make more sense to apply delays only once the database
> has reached a consistent state to be able to do immediately
> transaction-related operations on a standby without having to wait for
> it to reach consistency for perhaps a couple of hours. Please see
> attached a patch to do that.
>
>
I just reviewed the patch. It's pretty straightforward and works as
intended, so I mark it as ready for committer.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-03-02 23:29:32 | WHERE clause not used when index is used (9.5) |
Previous Message | Joe Conway | 2016-03-02 16:12:51 | Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower. |