Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: vignesh C <vignesh21@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Alexander Lakhin <exclusion@gmail.com>, Vitaly Davydov <v.davydov@postgrespro.ru>, 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-17T20:18:30Z
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().

vignesh C <vignesh21@gmail.com> writes:
> While tracking buildfarm for one of other commits, I noticed this failure:
> TRAP: failed Assert("s->data.restart_lsn >=
> s->last_saved_restart_lsn"), File:
> "../pgsql/src/backend/replication/slot.c", Line: 1813, PID: 3945797

My animal mamba is also showing this assertion failure, but in a
different test (recovery/t/040_standby_failover_slots_sync.pl).
It's failed in two out of its three runs since ca307d5ce went in,
so it's more reproducible than scorpion's report, though still not
perfectly so.

I suspect that mamba is prone to this simply because it's slow,
although perhaps there's a different reason.  Anyway, happy to
investigate manually if there's something you'd like me to
check for.

			regards, tom lane