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  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: PoC: Make it possible to disallow WHERE-less UPDATE and DELETE
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: Unexpected memory usage for repeated inserts within plpgsql function