RE: 019_replslot_limit.pl might fail due to checkpoint skipped

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