Re: Issues with 2PC at recovery: CLOG lookups and GlobalTransactionData

Vitaly Davydov <v.davydov@postgrespro.ru>

From: "Vitaly Davydov" <v.davydov@postgrespro.ru>
To: "Michael Paquier" <michael@paquier.xyz>
Cc: "Postgres hackers" <pgsql-hackers@lists.postgresql.org>
Date: 2025-01-31T13:54:17Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Integrate FullTransactionIds deeper into two-phase code

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