Re: Physical replication slot advance is not persistent - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Physical replication slot advance is not persistent
Date
Msg-id 20200616072727.GA2361@paquier.xyz
Whole thread Raw
In response to Re: Physical replication slot advance is not persistent  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
Responses Re: Physical replication slot advance is not persistent
Re: Physical replication slot advance is not persistent
List 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

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: language cleanups in code and docs
Next
From: Michael Paquier
Date:
Subject: Re: BufFileRead() error signalling