Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while
Julien Rouhaud <julien.rouhaud@dalibo.com>
From: Julien Rouhaud <julien.rouhaud@dalibo.com>
To: Michael Paquier <michael.paquier@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Greg Clough <greg@gclough.com>,
PostgreSQL mailing lists <pgsql-bugs@postgresql.org>,
Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2016-03-02T22:55:29Z
Lists: pgsql-bugs
On 02/01/2016 13:14, Michael Paquier wrote: > On Thu, Dec 31, 2015 at 8:13 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> On Thu, Dec 31, 2015 at 12:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Andres Freund <andres@anarazel.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
Commits
-
Ignore recovery_min_apply_delay until recovery has reached consistent state
- a9613ee69246 9.4.7 landed
- f95f1ce003d1 9.5.2 landed
- d34794f7d556 9.6.0 landed