Re: [BUG] pg_basebackup from disconnected standby fails
От | Amit Kapila |
---|---|
Тема | Re: [BUG] pg_basebackup from disconnected standby fails |
Дата | |
Msg-id | CAA4eK1+RsERBHqeikzHS_PaQLGWPHonkzBRPMehOzhMy-AcM9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG] pg_basebackup from disconnected standby fails (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [BUG] pg_basebackup from disconnected standby fails
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: