Re: An improvement of ProcessTwoPhaseBuffer logic
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Давыдов Виталий <v.davydov@postgrespro.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-27T07:37:02Z
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 →
-
Integrate FullTransactionIds deeper into two-phase code
- 62a17a92833d 19 (unreleased) landed
-
Merge copies of converting an XID to a FullTransactionId.
- 1587f7b9fc1a 17.3 landed
- 81772a495ec9 18.0 landed
-
Revert recent changes related to handling of 2PC files at recovery
- 4d6d7bdc0642 13.19 landed
- 060f9f5ea537 14.16 landed
- 42c900d31e57 15.11 landed
- 4d72357c40ee 16.7 landed
- d1bf86a62211 17.3 landed
- a6c70f68cdeb 18.0 landed
-
Fix failures with incorrect epoch handling for 2PC files at recovery
- c3de0f9eed38 17.3 landed
- 7e125b20eed6 18.0 landed
Attachments
- v2-0001-Fix-failure-with-incorrect-epoch-handling-for-2PC.patch (text/x-diff) patch v2-0001
On Thu, Dec 26, 2024 at 06:11:25PM +0300, Давыдов Виталий wrote: > I concerned about twophase file name generation. The function > TwoPhaseFilePath() is pretty straitforward and unambiguous in 16 and > earlier versions. The logic of this function in 17+ seems to be more > complex. I do not understand it clearly. But, I guess, it will work > incorrectly after turning to a newer epoch, because the epoch is > calculated from TransamVariables->nextXid, but not from problem > xid. The same problem may happen if we are in epoch 1 or greater. It > will produce a wrong file name, because the epoch will be obtained > from the last xid, not from file name xid. In another words, the > function AdjustToFullTransactionId assumes that if xid > > TransamVariables->nextXid, then the xid from the previous epoch. I > may be not the case in our scenario. Yeah. At this stage, we can pretty much say that the whole idea of relying AdjustToFullTransactionId() is broken, because we would build 2PC file names based on wrong assumptions, while orphaned files could be in the far past or far future depending on the epoch. TBH, we'll live better if we remove AdjustToFullTransactionId() and sprinkle a bit more the knowledge of FullTransactionIds to build correctly the 2PC file path in v17~. I've been playing with this code for a couple of hours and finished with the attached patch. I have wondered if ReadTwoPhaseFile() should gain the same knowledge as TwoPhaseFilePath(), but decided to limit the invasiness because we always call ReadTwoPhaseFile() once we don't have any orphaned files, for all the phases of recovery. So while this requires a bit more logic that depends on FullTransactionIdFromEpochAndXid() and ReadNextFullTransactionId() to build a FullTransactionId and get the current epoch, that's still acceptable as we only store an XID in the 2PC file. So please see the attached. You will note that RemoveTwoPhaseFile(), ProcessTwoPhaseBuffer() and TwoPhaseFilePath() now require a FullTransactionId, hence callers need to think about the epoch to use. That should limit future errors compared to passing the file name as optional argument. What do you think? -- Michael