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_lsnAND 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
beforecurrent 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
