|From:||Magnus Hagander <magnus(at)hagander(dot)net>|
|To:||Craig Ringer <craig(at)2ndquadrant(dot)com>|
|Cc:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Function to move the position of a replication slot|
|Views:||Raw Message | Whole Thread | Download mbox|
On Thu, Aug 17, 2017 at 2:19 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 17 August 2017 at 07:30, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
>> 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.
> ERROR's on logical slot, for now. Physical slots 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.
PFA an updated and rebased patch.
Rebased. Now named pg_advance_replication_slot. ERROR on logical slots.
I think that, in the end, covered all the comments?
|Next Message||Nikolay Shaplov||2017-08-31 12:29:45||Re: pgbench tap tests & minor fixes.|
|Previous Message||Simon Riggs||2017-08-31 11:54:35||Re: More replication race conditions|