Horton

Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

vignesh C <vignesh21@gmail.com>

View thread
From: vignesh C <vignesh21@gmail.com>
To: Vitaly Davydov <v.davydov@postgrespro.ru>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Alexander Korotkov <aekorotkov@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alexander Lakhin <exclusion@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>, "tomas@vondra.me" <tomas@vondra.me>
Date: 2025-06-18T10:03:17Z
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. Update comment for ReplicationSlot.last_saved_restart_lsn

  2. Fix CheckPointReplicationSlots() with max_replication_slots == 0

  3. Remove excess assert from InvalidatePossiblyObsoleteSlot()

  4. Improve runtime and output of tests for replication slots checkpointing.

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

  6. Fix an assert in CheckPointReplicationSlots().

On Wed, 18 Jun 2025 at 14:35, Vitaly Davydov <v.davydov@postgrespro.ru> wrote:
>
> Dear Hayato,
>
> > To confirm, can you tell me the theory why the walsender received old LSN?
> > It is sent by the walreceiver, so is there a case that LogstreamResult.Flush can go backward?
> > Not sure we can accept the situation.
>
> I can't say anything about the origin of the issue, but it can be easily reproduced
> on the master branch:
>
> 1. Add an assert in PhysicalConfirmReceivedLocation (apply the attached patch)
> 2. Compile & install with tap tests and assertions enabled
> 3. cd src/bin/pg_basebackup/
> 3. PROVE_TESTS=t/020_pg_receivewal.pl gmake check

Thanks for the steps, I was able to reproduce the issue with the
suggested steps.

> The test will fail because of the assertion. I plan to investigate the issue
> but I need some more time for it. Once, it happens on the original master
> branch, I think, this problem already exists. The proposed patch seems
> to be not guilty.

This issue occurs even prior to this commit, I was able to reproduce
it on a version just before it. I’ll also look into analyzing the root
cause further.

> It may be the same problem as discussed in:
> https://www.postgresql.org/message-id/CALDaNm2uQbhEVJzvnja6rw7Q9AYu9FpVmET%3DTbwLjV3DcPRhLw%40mail.gmail.com

This issue was related to confirmed_flush and was addressed in commit
d1ffcc7fa3c54de8b2a677a3e503fc808c7b419c. It is not related to
restart_lsn.

Regards,
Vignesh