Dear Alexander,
I checked your test and reproduced the issue with it.
Was it possible that INSERT happened in-between wait_for_replay_catchup and
teardown_node? In this case we may not ensure WAL records generated in the time
window were reached, right?
Similar stuff won7t happen in 009_twophase.pl because it does not have the bg
activities.
Obtained log around here is shown in [1].
[1]
```
2026-02-13 10:34:56.751 JST client backend[521764] 099_change_roles.pl LOG:
statement: INSERT INTO t VALUES (1000 * 1 + 2812, 'background activity');
2026-02-13 10:34:56.753 JST client backend[521762] 099_change_roles.pl LOG:
statement: SELECT '0/030ED4F8' <= replay_lsn AND state = 'streaming'
* from wait_for_replay_catchup
FROM pg_catalog.pg_stat_replication
WHERE application_name IN ('node2', 'walreceiver')
2026-02-13 10:34:56.762 JST client backend[521767] 099_change_roles.pl LOG:
statement: INSERT INTO t VALUES (1000 * 1 + 2813, 'background activity');
* do INSERT from background activities
2026-02-13 10:34:56.764 JST client backend[521768] 099_change_roles.pl LOG:
statement: INSERT INTO t VALUES (1000 * 2 + 2629, 'background activity');
2026-02-13 10:34:56.765 JST postmaster[521622] LOG: received immediate
shutdown request
* from teardown_node
2026-02-13 10:34:56.767 JST postmaster[521622] LOG: database system is shut
down
2026-02-13 10:34:56.996 JST postmaster[521844] LOG: starting PostgreSQL
19devel on x86_64-linux, compiled by gcc-11.5.0, 64-bit
....
2026-02-13 10:34:57.124 JST walreceiver[521864] LOG: replication terminated by
primary server
2026-02-13 10:34:57.124 JST walreceiver[521864] DETAIL: End of WAL reached on
timeline 153 at 0/030ED6D8.
2026-02-13 10:34:57.124 JST startup[521855] LOG: new timeline 154 forked off
current database system timeline 153 before current recovery point 0/030ED750
2026-02-13 10:34:57.124 JST walreceiver[521864] LOG: restarted WAL streaming
at 0/03000000 on timeline 153
```
Best regards,
Hayato Kuroda
FUJITSU LIMITED
