On Fri, Feb 23, 2024 at 10:41 PM Давыдов Виталий
<v.davydov@postgrespro.ru> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> I don't see we do anything specific for 2PC transactions to make them behave differently than regular transactions
withrespect to synchronous_commit setting. What makes you think so? Can you pin point the code you are referring to?
>
> Yes, sure. The function RecordTransactionCommitPrepared is called on prepared transaction commit (twophase.c). It
callsXLogFlush unconditionally. The function RecordTransactionCommit (for regular transactions, xact.c) calls XLogFlush
ifsynchronous_commit > OFF, otherwise it calls XLogSetAsyncXactLSN.
>
> There is some comment in RecordTransactionCommitPrepared (by Bruce Momjian) that shows that async commit is not
supportedyet:
> /*
> * We don't currently try to sleep before flush here ... nor is there any
> * support for async commit of a prepared xact (the very idea is probably
> * a contradiction)
> */
> /* Flush XLOG to disk */
> XLogFlush(recptr);
>
It seems this comment is added in the commit 4a78cdeb where we added
async commit support. I think the reason is probably that when the WAL
record for prepared is already flushed then what will be the idea of
async commit here?
> Right, I think for this we need to implement parallel apply.
>
> Yes, parallel apply is a good point. But, I believe, it will not work if asynchronous commit is not supported. You
haveonly one receiver process which should dispatch incoming messages to parallel workers. I guess, you will never
reachsuch rate of parallel execution on replica as on the master with multiple backends.
>
>
> Can you be a bit more specific about what exactly you have in mind to achieve the above solutions?
>
> My proposal is to implement async commit for 2PC transactions as it is for regular transactions. It should
significantlyspeedup the catchup process. Then, think how to apply in parallel, which is much diffcult to do. The
currentproblem is to get 2PC state from the WAL on commit prepared. At this moment, the WAL is not flushed yet, commit
functionwaits until WAL with 2PC state is to be flushed. I just tried to do it in my sandbox and found such a problem.
Inabilityto get 2PC state from unflushed WAL stops me right now. I think about possible solutions.
>
At commit prepared, it seems we read prepare's WAL record, right? If
so, it is not clear to me do you see a problem with a flush of
commit_prepared or reading WAL for prepared or both of these.
--
With Regards,
Amit Kapila.