Re: [BUG] pg_basebackup from disconnected standby fails
| От | Michael Paquier |
|---|---|
| Тема | Re: [BUG] pg_basebackup from disconnected standby fails |
| Дата | |
| Msg-id | CAB7nPqQ97UmsWaXCxdFsMkoZn+98ouch=2WQcLs9MEQZfWNX3g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [BUG] pg_basebackup from disconnected standby fails (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [BUG] pg_basebackup from disconnected standby fails
|
| Список | pgsql-hackers |
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... -- Michael
Вложения
В списке pgsql-hackers по дате отправления: