Horton

RE: Newly created replication slot may be invalidated by checkpoint

Vitaly Davydov <v.davydov@postgrespro.ru>

View thread
From: "Vitaly Davydov" <v.davydov@postgrespro.ru>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, pgsql-hackers@lists.postgresql.org, amit.kapila16@gmail.com
Cc: suyu.cmj <mengjuan.cmj@alibaba-inc.com>, "tomas" <tomas@vondra.me>, "michael" <michael@paquier.xyz>, bharath.rupireddyforpostgres <bharath.rupireddyforpostgres@gmail.com>, "Alexander Korotkov" <aekorotkov@gmail.com>, "Masahiko Sawada" <sawada.mshk@gmail.com>
Date: 2025-12-08T16:39:46Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Prevent invalidation of newly synced replication slots.

  2. Prevent invalidation of newly created replication slots.

  3. Fix re-distributing previously distributed invalidation messages during logical decoding.

  4. Keep WAL segments by the flushed value of the slot's restart LSN

  5. Keep WAL segments by slot's last saved restart LSN

On Monday, December 08, 2025 13:24 MSK, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com> wrote:

> On Monday, December 8, 2025 5:47 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > > Sawada-san/Vitaly, do you have any opinion on patch or the direction
> > > > to fix? The idea is to get this fixed for HEAD and 18, then continue
> > > > discussion for other bank-branches and the remaining patches.

Hi Amit, Zhijie Hou

Thank you for preparing and comiting 0001 patch. I'm ok with it. I did some auto
testing of the patch and haven't found any problems. As I realized, another two
patches (0002, 0003) are still in review.

In my previous email I wrote about copy_replication_slot, where restart_lsn is
assigned without any locks, but I'm not sure that email was successfully
delivered. Masahiko Sagawa mentioned about it in one of the latest emails as
well. I also read the answer but not completely understood it at the moment,
sorry (need some more time to investigate). Anyway, I would prefer to use locks
in create_physical_replication_slot rather than rely on signals handling which
may be changed in the future.

One more thing, when we copy a logical replication slot,
DecodingContextFindStartpoint reads the WAL from the specified restart_lsn which
may be removed by a concurrent checkpoint. It can produce an error and stop slot
copying, I guess. This behaviour may be not desirable.

With best regards,
Vitaly