Horton

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

Alexander Law <exclusion@gmail.com>

View thread View on postgr.es
From: Alexander Lakhin <exclusion@gmail.com>
To: Michael Paquier <michael@paquier.xyz>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Aleksander Alekseev <aleksander@timescale.com>
Date: 2026-03-04T08:00:00Z
Lists: pgsql-hackers 
Hello Michael,

04.03.2026 07:31, Michael Paquier wrote
>> I guess so. cluster::stop does the `pg_ctl stop -m fast` command. In this case
>> the walsender waits till there are nothing to be sent, see WalSndLoop().
>> Do let me know if you have observed the similar failure here.
> Exactly.  Doing a clean stop of the primary offers a strong guarantee
> here.  We are sure that the standby will have received all the records
> from the primary.  Timeline forking is an impossible thing in
> 012_subtransactions.pl based on how the switchover from the primary to
> the standby happens.  I don't see a need for tweaking this test at
> all.  Or perhaps you did see a failure of some kind in this test,
> Alexander?


Yes, 012_subtransactions doesn't fail with aggressive bgwriter, as I noted
before. I mentioned it exactly to show that stop does matter here. But if
we recognize teardown_node in this context as risky, maybe it would make
sense to review also other tests in recovery/. I already wrote about
004_timeline_switch, but probably there are more. E.g., 028_pitr_timelines
(I haven't tested it intensively yet) does:
$node_primary->stop('immediate');

# Promote the standby, and switch WAL so that it archives a WAL segment
# that contains all the INSERTs, on a new timeline.
$node_standby->promote;

Best regards,
Alexander

Commits

  1. Fix rare instability in recovery TAP test 004_timeline_switch

  2. Fix rare instability in recovery TAP test 009_twophase