Horton

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

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Alexander Lakhin <exclusion@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-15T09:50:18Z
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().

Hi, Alexander!

On Sun, Jun 15, 2025 at 12:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>
> Hello Alexander,
>
> 10.06.2025 23:14, Alexander Korotkov wrote:
>
> So, my proposal is to commit the attached patchset to the HEAD, and
> commit [1] to the back branches.  Any objections?
>
>
> As the buildfarm animal prion shows [1], the 046_checkpoint_logical_slot
> test fails with "-DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE":
> # poll_query_until timed out executing this query:
> #
> #         SELECT count(*) > 0 FROM pg_stat_activity
> #         WHERE backend_type = 'client backend' AND wait_event = 'logical-replication-slot-advance-segment'
> #
> # expecting this output:
> # t
> # last actual query output:
> # f
> # with stderr:
> [04:16:27] t/046_checkpoint_logical_slot.pl ......
> Dubious, test returned 29 (wstat 7424, 0x1d00)
> No subtests run
> [04:20:58] t/047_checkpoint_physical_slot.pl ..... ok   271294 ms ( 0.00 usr  0.00 sys +  0.37 cusr  0.26 csys =  0.63 CPU)
>
> I'm able to reproduce this locally as well. Though the test passes for me
> with the increased timeout, that is it's not stuck:
> PG_TEST_TIMEOUT_DEFAULT=360 PROVE_TESTS="t/046*" make -s check -C src/test/recovery/
> # +++ tap check in src/test/recovery +++
> t/046_checkpoint_logical_slot.pl .. ok
> All tests successful.
> Files=1, Tests=1, 533 wallclock secs ( 0.01 usr  0.00 sys +  4.70 cusr  9.61 csys = 14.32 CPU)
> Result: PASS
>
> Could you have a look?
>
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2025-06-14%2001%3A58%3A06

Hmm... It seems to take too long to advance the segment with these
options on.  Sure, I'll check this!

------
Regards,
Alexander Korotkov
Supabase