Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while
От | Julien Rouhaud |
---|---|
Тема | Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while |
Дата | |
Msg-id | 56D76F61.5060504@dalibo.com обсуждение исходный текст |
Ответ на | Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #13770: Extending recovery_min_apply_delay on Standby
causes it to be unavailable for a while
|
Список | 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
В списке pgsql-bugs по дате отправления: