Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 9 Jul 2025 16:35:23 +0900
From: Michael Paquier <michael@paquier.xyz>
To: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Subject: Re: The same 2PC data maybe recovered twice
Message-ID: <aG4bu_50RhPGdwSK@paquier.xyz>
References: 
 <0706bec1-80ae-4f99-8cf8-c89734978770.mengjuan.cmj@alibaba-inc.com>
 <CAKU4AWoxK9VP1ZqChmUhU+AQ86oJsq7Fu2-SRzXwA2Jr76MsNA@mail.gmail.com>
 <27cf1fe2-e8f9-4fca-a828-aa3ad3397acd.mengjuan.cmj@alibaba-inc.com>
 <ZK+gsMyGRqHbIpyK@paquier.xyz>
 <02595127-20e2-454e-a4fe-0a7e376a1917.mengjuan.cmj@alibaba-inc.com>
 <ZLT0+RtNqRNqXKUz@paquier.xyz>
 <5179d749-cae2-4eb6-8dbc-c97e827d7ce5.mengjuan.cmj@alibaba-inc.com>
 <ZLYfkPNovHH+IIhE@paquier.xyz>
 <c2307b91-de84-445f-8881-a4ea06b5421d.mengjuan.cmj@alibaba-inc.com>
 <b6d0389e-fd32-4071-9c93-3123cdfeb0ba.mengjuan.cmj@alibaba-inc.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="+3RCvOUg+hH93+qO"
Content-Disposition: inline
In-Reply-To: 
 <b6d0389e-fd32-4071-9c93-3123cdfeb0ba.mengjuan.cmj@alibaba-inc.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aG4bu_50RhPGdwSK%40paquier.xyz>
Precedence: bulk


--+3RCvOUg+hH93+qO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 09, 2025 at 01:51:03PM +0800, suyu.cmj wrote:
> Currently, since restoreTwoPhaseData() is the only function that
> restores 2PC transactions from disk before the recovery starts,
> after reaching a consistent state, the 2PC transactions are only
> added from the WAL. Under normal circumstances, there should not be
> any corresponding 2PC files on the storage at that point. Therefore,
> I prefer to perform the file access checks only when the server has
> not yet reached a consistent state. Once consistency has been
> reached, if a duplicate 2PC transaction is added, it will directly
> result in an error in the subsequent replay logic.=20

There is a bit more going on in this code that needs to be fixed.

Please see the following thread, that also relates to the state of the
2PC recovery code when we read them from disk at the beginning of
recovery, with the bottom part being the most relevant:
https://www.postgresql.org/message-id/Z5sd5O9JO7NYNK-C%40paquier.xyz
--
Michael

--+3RCvOUg+hH93+qO
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmhuG7sACgkQnvQgOdby
QH0E2Q//cDMdt+wDFriqnkvZsIP6pC3JwKt4gsod0Q4kMFQsUL3DK9f0Ii9Igvsa
vMPV3tEq04LKbistPUXX5q29qoMmUYaFOW98ahPK0vgHKRd8r/+MXrLJUq2Pk675
bxtZLCLZzOmUA7VVcYHZ/lRlQrtMjIVbTdLP00+Ec1KbXpulhVgym1jcVSmxKaqF
UrYZvy+MAtdUaF1/oHaIUacSn/sU+bUSfx7XfIk+R+601CjEt4ns8glhVu6DQ7Bs
Qd1tYFFv3pLUe6bWjMBK7ARec63fcXdnornYCxpyEEyWY8xYaiH28NDEIRLm3WvJ
m8fwQlShFHPbKqNdtyWQEesv3wKSmAA3NBvzJ6Mf63z38S53+k4eoizQMeNgimi6
qTZqL2o/47285qrjbjAY3T8hdrP9EYNBR/LA4NjB005eas6CeRUkZWILN+HCnHKk
aNEZOv7Mwl3GZhrLz7o4L5boJsZD6M7xZ654yO2lL0jrKRTbvGQsFjnd7P/KwuXm
UEPpbtdHEDGyClBWnvBwrVO6gyceiMSKmyB+kMNuY1Eucdw2Nx4+XvfRn97+x/rX
lh5WmVW5WUPSYDfC5/L9mdFuu+IbM4tPLvQva7gq7m5Y2AWc9rwiNRzYEhPFhymZ
yCKC9B3+Z2rfpKSiyASmEF6dFHMoOqMAjKi53rBhkdk0s/Q/BjA=
=PGFR
-----END PGP SIGNATURE-----

--+3RCvOUg+hH93+qO--