Re: [HACKERS] Function to move the position of a replication slot
От | Magnus Hagander |
---|---|
Тема | Re: [HACKERS] Function to move the position of a replication slot |
Дата | |
Msg-id | CABUevEz0OSH+z-HtSoHuioEcvzD=+AADvZjvx2-yxhHM4+8-ow@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Function to move the position of a replication slot (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Function to move the position of a replication slot
Re: [HACKERS] Function to move the position of a replication slot |
Список | pgsql-hackers |
On Thu, Aug 17, 2017 at 2:19 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 17 August 2017 at 07:30, Michael Paquier <michael.paquier@gmail.com> wrote:
Definitely agreed on that. Any move function would need to check if
the WAL position given by caller is already newer than what's
available in the local pg_wal (minimum of all other slots), with a
shared lock that would need to be taken by xlog.c when recycling past
segments. A forward function works on a single entry, which should be
disabled at the moment of the update. It looks dangerous to me to do
such an operation if there is a consumer of a slot currently on it.pg_advance_replication_slot(...) ERROR's on logical slot, for now. Physical slots only.Forward-only.Future work to allow it to use the logical decoding infrastructure to fast-forward a slot by reading only catalog change information and invalidations, either via a dummy output plugin that filters out all xacts, or by lower level use of the decoding code.Reasonable?
PFA an updated and rebased patch.
Rebased. Now named pg_advance_replication_slot. ERROR on logical slots. Forward only.
I think that, in the end, covered all the comments?
Вложения
В списке pgsql-hackers по дате отправления: