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

Alexander Lakhin <exclusion@gmail.com>

From: Alexander Lakhin <exclusion@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: 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
Date: 2025-06-15T15:00:01Z
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().

15.06.2025 14:02, Alexander Korotkov wrote:
> Could you, please, check this patch?  On my system it makes 046 and
> 047 execute in 140 secs with -O0 and -DRELCACHE_FORCE_RELEASE
> -DCATCACHE_FORCE_RELEASE.

Thank you for the patch!

It decreases the test's duration significantly:
# +++ tap check in src/test/recovery +++
t/046_checkpoint_logical_slot.pl .. ok
All tests successful.
Files=1, Tests=1, 29 wallclock secs ( 0.01 usr  0.00 sys +  0.23 cusr  0.56 csys =  0.80 CPU)

Without the patch:
t/046_checkpoint_logical_slot.pl .. ok
All tests successful.
Files=1, Tests=1, 519 wallclock secs ( 0.01 usr  0.00 sys +  3.05 cusr  7.64 csys = 10.70 CPU)
Result: PASS

Best regards,
Alexander