RE: BUG: Former primary node might stuck when started as a standby

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Alexander Lakhin' <exclusion@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Aleksander Alekseev <aleksander@timescale.com>
Date: 2026-02-13T02:03:01Z
Lists: pgsql-hackers
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

Commits

  1. Fix rare instability in recovery TAP test 004_timeline_switch

  2. Fix rare instability in recovery TAP test 009_twophase