Re: Issues with 2PC at recovery: CLOG lookups and GlobalTransactionData - Mailing list pgsql-hackers

From Vitaly Davydov
Subject Re: Issues with 2PC at recovery: CLOG lookups and GlobalTransactionData
Date
Msg-id c8936-679cd600-35-37d39a80@87852050
Whole thread Raw
List pgsql-hackers
On Friday, January 31, 2025 03:21 MSK, Michael Paquier <michael@paquier.xyz>
wrote:
> > Thoughts and comments are welcome.

I'm looking at the v13 patch. I see, there is the only file for v13:
v2-0002-Fix-issues-with-2PC-file-handling-at-recovery-13.txt

There are two points I would like to highlight:

#1. In RecoverPreparedTransactions we iterave over all in-memory two phase
states and check every xid state in CLOG unconditionally. Image, we have
a very old transaction that is close to the oldestXid. Will CLOG state be
available for such transaction? I'm not sure about it.

#2. In restoreTwoPhaseData we load all the twostate files that are in
the valid xid range (from oldestXid to nextFullXid in terms of logical
comparision of xids with epoch). The question - should we load files
which xids greater than ControlFile->checkPointCopy.nextXid
(xids after last checkpoint). In general, all twophase files should belong
to xids before the last checkpoint. I guess, we should probably ignore
files which xid is equal or greater than the xid of the last checkpoint -
twostate data should be in the WAL. If not, I guess, we may see error messages
like show below when doing xact_redo -> PrepareRedoAdd:

Two-phase state file has been found in WAL record %X/%X, but this transaction
has already been restored from disk

I'm not sure about the logic related to this message in PrepareRedoAdd.

P.S. Thank you for responses on my emails. I also apologize for the
formatting of my emails. I will check what is wrong and fix.

With best regards,
Vitaly




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: NOT ENFORCED constraint feature
Next
From: Jelte Fennema-Nio
Date:
Subject: Commitfest app release on Feb 17 with many improvements