On Thu, Oct 27, 2016 at 9:51 AM, Michael Paquier <[email protected]> wrote: > On Thu, Oct 27, 2016 at 2:59 AM, Robert Haas <[email protected]> wrote: >> On Wed, Oct 26, 2016 at 2:06 AM, Michael Paquier >> <[email protected]> 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
backup-standby-v6.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
