Content-Type: multipart/mixed; boundary="------------ofUzc5hrdSCjoELsLN2NsfZA"
Message-ID: <045cab6f-4738-417e-b551-01adba44d6c3@gmail.com>
Date: Fri, 20 Feb 2026 04: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: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
 Aleksander Alekseev <aleksander@timescale.com>
References: <b0102688-6d6c-c86a-db79-e0e91d245b1a@gmail.com>
 <CAJ7c6TOqnv7cZ53RfBv9towSDzNOUVQ74WzPeN7LwoKMuW4tOA@mail.gmail.com>
 <74ea5e7e-9aa0-4d7a-85df-71a9d200a8d8@gmail.com>
 <CAJ7c6TO-_=rfN0Mb1RrChmrQvLtXoWw9aDezwC9g48-Va3E2EQ@mail.gmail.com>
 <180bf13e-235d-46a9-9788-7d6cee40bcdc@gmail.com>
 <OS9PR01MB12149E6917AAC1560150B918BF565A@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <cfd35cfb-3216-42b1-814b-cc658fd0f099@gmail.com>
 <OS9PR01MB12149C0F968A40BA54BD4C16FF561A@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <e1cf52d2-c344-4dfd-a918-e5f20ff04fa2@gmail.com>
 <OS9PR01MB121498EFA4CBF3003B83C9BCCF56CA@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <63e55743-669e-4300-a561-7b7ff63723b6@gmail.com>
 <OS9PR01MB12149D4F1A2BC23637688CE4DF56BA@OS9PR01MB12149.jpnprd01.prod.outlook.com>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <OS9PR01MB12149D4F1A2BC23637688CE4DF56BA@OS9PR01MB12149.jpnprd01.prod.outlook.com>
Archived-At: 
 <https://www.postgresql.org/message-id/045cab6f-4738-417e-b551-01adba44d6c3%40gmail.com>
Precedence: bulk

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

Dear Kuroda-san,

19.02.2026 05:50, Hayato Kuroda (Fujitsu) wrote:
> Dear Alexander,
>
>> Unfortunately, the testing procedure I shared above still produces failures
>> with the patched 009_twophase.pl.
> Hmm, I ran the test for hours, but I could nor reproduce the failure. But let me analyze
> based on your log.

Please look at the attached self-contained script. It works for me (failed
on iterations 6, 12, 2 right now, on my workstation with Ryzen 7900X) --
probably you could adjust number of parallel jobs to reproduce it on your
hardware.

> I have few experience to see the wal_debug output, but background writer seems to
> generate the RUNNING_XACTS record. It's different from my expectation. To confirm,
> did you really enable the injection point? For now 009_twophase can work without
> the `-Dinjection_points=true` but it should be set to avoid random failures.

I think it failed before the injection was set. My log contains:
2026-02-17 07:06:44.313 EET client backend[754908] 009_twophase.pl STATEMENT:  PREPARE TRANSACTION 'xact_009_10';
2026-02-17 07:06:44.313 EET client backend[754908] 009_twophase.pl LOG:  xlog flush request 0/030227F8; write 
0/00000000; flush 0/00000000
2026-02-17 07:06:44.313 EET client backend[754908] 009_twophase.pl STATEMENT:  PREPARE TRANSACTION 'xact_009_10';
2026-02-17 07:06:44.313 EET background writer[754333] LOG:  INSERT @ 0/03022838:  - Standby/RUNNING_XACTS: nextXid 791 
latestCompletedXid 788 oldestRunningXid 789; 1 xacts: 789; 1 subxacts: 790

As far as I can see, it corresponds to this place in the test:
      SAVEPOINT s1;
      INSERT INTO t_009_tbl VALUES (22, 'issued to ${cur_primary_name}');
      PREPARE TRANSACTION 'xact_009_10';");
+$cur_primary->wait_for_replay_catchup($cur_standby);
  $cur_primary->teardown_node;
  $cur_standby->promote;

And as we found out before, wait_for_replay_catchup() before teardown
doesn't help... I can't say for sure, but from my experiments, the test
didn't fail with $cur_primary->stop instead of $cur_primary->teardown_node.

Best regards,
Alexander
--------------ofUzc5hrdSCjoELsLN2NsfZA
Content-Type: text/plain; charset=UTF-8; name="promote-issue-repro.sh.txt"
Content-Disposition: attachment; filename="promote-issue-repro.sh.txt"
Content-Transfer-Encoding: base64

CnNldCAtZQoKIyBnaXQgcmVzZXQgLS1oYXJkOyBnaXQgY2xlYW4gLWRmeCA+L2Rldi9udWxs
CgpnaXQgcmVzdG9yZSBzcmMvYmFja2VuZC9wb3N0bWFzdGVyL2Jnd3JpdGVyLmMKcGF0Y2gg
LXAxIDw8IEVPRgotLS0gYS9zcmMvYmFja2VuZC9wb3N0bWFzdGVyL2Jnd3JpdGVyLmMKKysr
IGIvc3JjL2JhY2tlbmQvcG9zdG1hc3Rlci9iZ3dyaXRlci5jCkBAIC02OSwzICs2OSwzIEBA
IGludAkJCUJnV3JpdGVyRGVsYXkgPSAyMDA7CiAgKi8KLSNkZWZpbmUgTE9HX1NOQVBTSE9U
X0lOVEVSVkFMX01TIDE1MDAwCisjZGVmaW5lIExPR19TTkFQU0hPVF9JTlRFUlZBTF9NUyAx
CiAKQEAgLTMwNywzICszMDcsMyBAQCBCYWNrZ3JvdW5kV3JpdGVyTWFpbihjb25zdCB2b2lk
ICpzdGFydHVwX2RhdGEsIHNpemVfdCBzdGFydHVwX2RhdGFfbGVuKQogCQkJCQkgICBXTF9M
QVRDSF9TRVQgfCBXTF9USU1FT1VUIHwgV0xfRVhJVF9PTl9QTV9ERUFUSCwKLQkJCQkJICAg
QmdXcml0ZXJEZWxheSAvKiBtcyAqLyAsIFdBSVRfRVZFTlRfQkdXUklURVJfTUFJTik7CisJ
CQkJCSAgIDEgLyogbXMgKi8gLCBXQUlUX0VWRU5UX0JHV1JJVEVSX01BSU4pOwogCkBAIC0z
NDAsMyArMzQwLDIgQEAgQmFja2dyb3VuZFdyaXRlck1haW4oY29uc3Qgdm9pZCAqc3RhcnR1
cF9kYXRhLCBzaXplX3Qgc3RhcnR1cF9kYXRhX2xlbikKIAotCQlwcmV2X2hpYmVybmF0ZSA9
IGNhbl9oaWJlcm5hdGU7CiAJfQpFT0YKCkNGTEFHUz0iLURXQUxfREVCVUciIC4vY29uZmln
dXJlIC1xIC0tZW5hYmxlLWRlYnVnIC0tZW5hYmxlLWNhc3NlcnQgLS1lbmFibGUtdGFwLXRl
c3RzIC0tZW5hYmxlLWluamVjdGlvbi1wb2ludHMKbWFrZSAtcyAtajgKUFJPVkVfVEVTVFM9
InQvMDA5KiIgbWFrZSAtcyBjaGVjayAtQyBzcmMvdGVzdC9yZWNvdmVyeQpmb3IgaSBpbiB7
MS4uNDB9OyBkbwogIGNwIC1yIHNyYy90ZXN0L3JlY292ZXJ5LyBzcmMvdGVzdC9yZWNvdmVy
eV8kaS87CiAgc2VkICJzfHNyYy90ZXN0L3JlY292ZXJ5fHNyYy90ZXN0L3JlY292ZXJ5XyRp
fCIgLWkgc3JjL3Rlc3QvcmVjb3ZlcnlfJGkvTWFrZWZpbGU7CmRvbmUKCmVjaG8gIndhbF9k
ZWJ1ZyA9IG9uCiIgPi90bXAvdGVtcC5jb25maWcKCmZvciBpIGluIHsxLi4xMDB9OyBkbwog
IGVjaG8gIklURVJBVElPTiAkaSI7CiAgcGFyYWxsZWwgLS1oYWx0IG5vdyxmYWlsPTEgLWo0
MCAtLWxpbmVidWZmZXIgLS10YWcgVEVNUF9DT05GSUc9L3RtcC90ZW1wLmNvbmZpZyBQUk9W
RV9URVNUUz0idC8wMDkqIiBOT19URU1QX0lOU1RBTEw9MSB0aW1lb3V0IDYwIG1ha2UgY2hl
Y2sgLXMgLUMgc3JjL3Rlc3QvcmVjb3Zlcnlfe30gOjo6IGBzZXEgMjBgIHx8IGJyZWFrOwpk
b25lCg==

--------------ofUzc5hrdSCjoELsLN2NsfZA--