Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 14 Jul 2025 17:14:43 +0900
From: Michael Paquier <michael@paquier.xyz>
To: "CAI, Mengjuan" <mengjuan.cmj@alibaba-inc.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: The same 2PC data maybe recovered twice
Message-ID: <aHS8c8-dPyTLijOW@paquier.xyz>
References: 
 <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>
 <012f3c16-1641-48be-b0b7-fbf194dc39e9.mengjuan.cmj@alibaba-inc.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="yYfkxjSty/MKuAiK"
Content-Disposition: inline
In-Reply-To: 
 <012f3c16-1641-48be-b0b7-fbf194dc39e9.mengjuan.cmj@alibaba-inc.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aHS8c8-dPyTLijOW%40paquier.xyz>
Precedence: bulk


--yYfkxjSty/MKuAiK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 14, 2025 at 02:46:25PM +0800, CAI, Mengjuan wrote:
> Thank you for your reply. I reviewed the thread you mentioned, and
> it seems that the issue needing to be fixed is not the same as the
> one I previously raised.
> I am considering whether the 2PC file check logic in
> PrepareRedoAdd() can be modified. Currently, each time a
> XLOG_XACT_PREPARE WAL entry is replayed, it checks for the
> corresponding 2PC file using access(). Each access operation creates
> a dentry in the OS, and in most cases, the file being accessed does
> not exist. When there are many 2PC transactions, this logic may lead
> to an increase in OS slab memory. In worse scenarios, it could cause
> the reference count of the parent directory's dentry to overflow,
> potentially leading to an OS crash. Typically, when accessing
> existing files, the disk will fill up before the dentry reference
> count overflows.=20
> Therefore, I would like to propose a modification. Attached is my
> patch for your review, and I hope you can take a look at it.

@@ -2520,8 +2520,16 @@ PrepareRedoAdd(FullTransactionId fxid, char *buf,
[...]
-	if (!XLogRecPtrIsInvalid(start_lsn))
+	if (!XLogRecPtrIsInvalid(start_lsn) && !reachedConsistency)

Actually, what you are doing is incorrect because we could miss some
ERRORs for example if a base backup was incorrect if come files were
present in pg_twophase?

It's not really true that what you are changing here has no
interaction with the beginning of recovery, the other thread is about
the fact that reading the 2PC files from disk when !reachedConsistency
is a bad concept that we should avoid, impacting the assumption the
code path you are changing here relies on.  At the end, it may be
possible that we're able to remove this check entirely..
--
Michael

--yYfkxjSty/MKuAiK
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmh0vHMACgkQnvQgOdby
QH1YZw//aUD3MwpimIsJ/A7glG8MVjNIcXc9Tij4gpns0vcSK00Md5ekCSx4fEp6
pZBxgivnlV7ZV7DtMunPCiWj+OENr6+eNZ3C7JZKDeZimf0GzwD5NC5tlssQDLlW
w20hGnjmVHrMPMyTWpQ0D7y9dZY9s/+dje2hdItf1igBdUKvuLZsQETJ3G8+TVkz
nG6lw6sG8CuctBdz9sCDxw/bvS7HkusYCvVY4UyKVam2YkiDrZNaNfLa0o+offFc
EN/cTUKKHVyVKuDDriEwrhfwJ7H0/1n2bxpbQxiloseu5YkdQE3x2KPIx3vNJAnh
1EDNAM02q9BnAcT70iHsQQgXzo55mlUfLN2NwJpVmljkg2pV5aGh+2B6S30ZTFOV
sPWouEmNrWfAKEYTeNh92qW1kJhRZLADQbiSGVmopKlRchMxienrZfOXhYcpPtSi
xmC22kXdqdsZ645uhYH8Nz/iQb9lPRwfCTxM90HtpWci3LLOxJNGrwq0tpspnRDs
MtnR+0EqSio3NQ7lQipvxEhEpSFbVFGIUaoz9U8HEp7cAzYg425W0VqcbsusFdoM
Hw12fN0IyI4VbqyMxk0NzXqUJpInOdxyjCOTCa+RWF7gxemgA8+oy6X45FfRqsMd
0ApYocv6JolwpJzbZtiPbSFABmF02B7jrMs/W9Usfo5p/TGpDlw=
=BwRE
-----END PGP SIGNATURE-----

--yYfkxjSty/MKuAiK--