Re: [BUG] pg_basebackup from disconnected standby fails
От | Michael Paquier |
---|---|
Тема | Re: [BUG] pg_basebackup from disconnected standby fails |
Дата | |
Msg-id | CAB7nPqSQgt280LtSW9EgX7CvU4JwVraMmOQTM42NM-qyXAkFOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG] pg_basebackup from disconnected standby fails (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [BUG] pg_basebackup from disconnected standby fails
|
Список | pgsql-hackers |
On Thu, Jul 21, 2016 at 5:19 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > + * minRecoveryPoint can go behind the last checkpoint's redo location when > + * the checkpoint writes out no buffer. This does no harm to performing a > + * recovery but such inversion seems inconsistent from the view of the > + * callers and prevents them from knowing WAL segments needed by sane > + * calcuation. For the reason we return the last replayed point as the > + * backup end location. Note that it can be greater than the exact backup > + * end location or even the minimum recovery point of pg_control at the > + * time. This is harmless for current uses. It does not seem an improvement to me to mention a comment regarding minRecoveryPoint in do_pg_stop_backup, especially knowing that the patch that we have here uses the last replayed LSN and TLI and does not care about that anymore. > AFAICS pg_stop_backup returns a single value of LSN. I don't know > where this comes from, but the attached patch fixes this and adds > a mention on the "gap". The original description mentioned > backup_label and tablespace_map but it seems not necessary. The > following is the new content rewritten by the patch. No, this second patch is wrong. This part of the docs refers to non-exclusive backups, where 3 fields are returned. So the docs are correct. -- Michael
В списке pgsql-hackers по дате отправления: