On Thu, Oct 27, 2016 at 9:51 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Oct 27, 2016 at 2:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Oct 26, 2016 at 2:06 AM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> But yes, thinking *harder*, I agree that updating minRecoveryPoint
>>> just after the checkpoint record would be fine and removes the need to
>>> have more WAL than necessary in for a backup taken from a standby.
>>> That will also prevent cases where minRecoveryPoint is older than the
>>> recovery start point. On top of that the cost of an extra call to
>>> UpdateControlFile() looks cheap considering that CreateRestartPoint()
>>> is called only by the checkpointer or at shutdown.
>>>
>>> Just coding things this solution gives roughtly the attached? The TAP
>>> test passes btw.
>>
>> I think that still leaves a race condition, right? It's got to be
>> part of the SAME control file update that advances the redo pointer.
>
> Right, thanks for double-checking... There is no meaning to do that
> out of the ControlFileLock taken previously...
>
+ if (ControlFile->minRecoveryPoint < lastCheckPointRecPtr)
+ {
+ ControlFile->minRecoveryPoint = lastCheckPointRecPtr;
+ ControlFile->minRecoveryPointTLI = ThisTimeLineID;
This can create problem if the checkpoint record spans across multiple
segments, because you are updating minRecoveryPoint to start of
checkpoint record. We need to update it to end+1 of checkpoint
record. Please find attached patch which takes care of same.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com