On Thu, Oct 27, 2016 at 9:51 AM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Thu, Oct 27, 2016 at 2:59 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Wed, Oct 26, 2016 at 2:06 AM, Michael Paquier
>> <michael.paqu...@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

Attachment: backup-standby-v6.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to