On Fri, Feb 23, 2024 at 10:41 PM Давыдов Виталий <v.davy...@postgrespro.ru> wrote: > > Amit Kapila <amit.kapil...@gmail.com> wrote: > > I don't see we do anything specific for 2PC transactions to make them behave > differently than regular transactions with respect 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 calls XLogFlush unconditionally. The > function RecordTransactionCommit (for regular transactions, xact.c) calls > XLogFlush if synchronous_commit > OFF, otherwise it calls XLogSetAsyncXactLSN. > > There is some comment in RecordTransactionCommitPrepared (by Bruce Momjian) > that shows that async commit is not supported yet: > /* > * 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 have only one receiver process > which should dispatch incoming messages to parallel workers. I guess, you > will never reach such 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 significantly speedup the catchup process. > Then, think how to apply in parallel, which is much diffcult to do. The > current problem is to get 2PC state from the WAL on commit prepared. At this > moment, the WAL is not flushed yet, commit function waits until WAL with 2PC > state is to be flushed. I just tried to do it in my sandbox and found such a > problem. Inability to 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.
