Dear Alexander, > Investigating a recent buildfarm failure [1] with the following > diagnostics: > [12:27:41.437](0.024s) ok 18 - have walreceiver pid 637143 > [12:30:42.564](181.127s) not ok 19 - walsender termination logged > [12:30:42.564](0.000s) > [12:30:42.564](0.000s) # Failed test 'walsender termination logged' > # at t/019_replslot_limit.pl line 382.
Sorry for replying to the old thread, I found it happened again [1].
> I've found that such a failure can occur when the checkpoint, which should
> invalidate replication slot (through the call chain: CreateCheckPoint() ->
> InvalidateObsoleteReplicationSlots() -> InvalidatePossiblyObsoleteSlot()),
> is skipped.
>
> I've managed to reproduce this with the following sleep() added inside
> src/backend/access/transam/xlog.c:
> @@ -7126,6 +7126,11 @@ CreateCheckPoint(int flags)
> * panic. Accordingly, exit critical section while doing it.
> */
> END_CRIT_SECTION();
> +if (rand() % 2 == 0)
> +{
> +elog(LOG, "!!!CreateCheckPoint| sleeping...");
> +pg_usleep(1000000);
> +}
I confirmed that this method is still valid: I used the below variant:
```
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7663,6 +7663,9 @@ CreateCheckPoint(int flags)
*/
END_CRIT_SECTION();
+ elog(LOG, "checkpoint paused");
+ pg_usleep(5 * 1000000L);
```
IIUC, the workaround is to force the CHECKPOINT after advancing WAL segments.
Also, we can increase the max_wal_size to avoid the checkpoint due to WAL files.
Please see attached. How do you feel?
[1]:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=partridge&dt=2026-08-06%2018%3A00%3A11
Best regards,
Hayato Kuroda
FUJITSU LIMITED
0001-Stablize-019_replslot_limit.patch
Description: 0001-Stablize-019_replslot_limit.patch
