Re: Physical replication slot advance is not persistent

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Physical replication slot advance is not persistent
Дата
Msg-id 20200616072727.GA2361@paquier.xyz
обсуждение исходный текст
Ответ на Re: Physical replication slot advance is not persistent  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
Ответы Re: Physical replication slot advance is not persistent  (Michael Paquier <michael@paquier.xyz>)
Re: Physical replication slot advance is not persistent  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
Список pgsql-hackers
On Wed, Jun 10, 2020 at 08:57:17PM +0300, Alexey Kondratov wrote:
> New test reproduces this issue well. Left it running for a couple of hours
> in repeat and it seems to be stable.

Thanks for testing.  I have been thinking about the minimum xmin and
LSN computations on advancing, and actually I have switched the
recomputing to be called at the end of pg_replication_slot_advance().
This may be a waste if no advancing is done, but it could also be an
advantage to enforce a recalculation of the thresholds for each
function call.  And that's more consistent with the slot copy, drop
and creation.

> we can safely use $current_lsn used for pg_replication_slot_advance(), since
> reatart_lsn is set as is there. It may make the test a bit simpler as well.

We could do that.  Now I found cleaner the direct comparison of
pg_replication_slots.restart before and after the restart.  So I have
kept it.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: language cleanups in code and docs
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BufFileRead() error signalling