Horton

Re: Physical replication slot advance is not persistent

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Alexey Kondratov <a.kondratov@postgrespro.ru>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, andres@anarazel.de, dim@tapoueh.org, pgsql-hackers@postgresql.org, simon@2ndquadrant.com
Date: 2020-06-16T07:27:27Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Fix oldest xmin and LSN computation across repslots after advancing

  2. Fix slot data persistency when advancing physical replication slots