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