Content-Type: multipart/alternative;
 boundary="------------1mXXB5OE4ZMBBfPuHgGe00Xs"
Message-ID: <9d4abbe2-95aa-47e0-9ce2-842196a662a7@gmail.com>
Date: Wed, 4 Mar 2026 10:00:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG: Former primary node might stuck when started as a standby
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>
References: 
 <OS9PR01MB121498EFA4CBF3003B83C9BCCF56CA@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <63e55743-669e-4300-a561-7b7ff63723b6@gmail.com>
 <OS9PR01MB12149D4F1A2BC23637688CE4DF56BA@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <045cab6f-4738-417e-b551-01adba44d6c3@gmail.com>
 <c7284102-01fb-4704-8a80-8e65f59fa933@gmail.com>
 <aaU5EiNHfyMb9Bvu@paquier.xyz>
 <TYRPR01MB12156CC5A9AC774B07FA7E40BF57FA@TYRPR01MB12156.jpnprd01.prod.outlook.com>
 <aaZ77VvZ4Oabp30A@paquier.xyz>
 <493401a8-063f-436a-8287-a235d9e065fc@gmail.com>
 <OS9PR01MB121491FE3BD5D9D7341B83537F57FA@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <aafDsb5snkfkNfdS@paquier.xyz>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <aafDsb5snkfkNfdS@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/9d4abbe2-95aa-47e0-9ce2-842196a662a7%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------1mXXB5OE4ZMBBfPuHgGe00Xs
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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
--------------1mXXB5OE4ZMBBfPuHgGe00Xs
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Michael,<br>
      <br>
      04.03.2026 07:31, Michael Paquier wrote<br>
    </div>
    <blockquote type="cite" cite="mid:aafDsb5snkfkNfdS@paquier.xyz">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">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.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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?
</pre>
    </blockquote>
    <br>
    <br>
    Yes, 012_subtransactions doesn't fail with aggressive bgwriter, as I
    noted<br>
    before. I mentioned it exactly to show that stop does matter here.
    But if<br>
    we recognize teardown_node in this context as risky, maybe it would
    make<br>
    sense to review also other tests in recovery/. I already wrote about<br>
    004_timeline_switch, but probably there are more. E.g.,
    028_pitr_timelines<br>
    (I haven't tested it intensively yet) does:<br>
    $node_primary-&gt;stop('immediate');<br>
    <br>
    # Promote the standby, and switch WAL so that it archives a WAL
    segment<br>
    # that contains all the INSERTs, on a new timeline.<br>
    $node_standby-&gt;promote;<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------1mXXB5OE4ZMBBfPuHgGe00Xs--