Re: Slow catchup of 2PC (twophase) transactions on replica in LR
От | Давыдов Виталий |
---|---|
Тема | Re: Slow catchup of 2PC (twophase) transactions on replica in LR |
Дата | |
Msg-id | ba4b6-65ddc580-9-5c3e3080@134362348 обсуждение исходный текст |
Ответ на | Re: Slow catchup of 2PC (twophase) transactions on replica in LR (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Slow catchup of 2PC (twophase) transactions on replica in LR
|
Список | pgsql-hackers |
Hi Amit,
Thank you for your interest in the discussion!
On Monday, February 26, 2024 16:24 MSK, Amit Kapila <amit.kapila16@gmail.com> wrote:
I did some experiments with saving 2PC state in the local memory of logical replication worker and, I think, it worked and demonstrated much better performance. Logical replication worker utilized up to 100% CPU. I'm just concerned about possible problems with async commit for twophase transactions.
To be more specific, I've attached a patch to support async commit for twophase. It is not the final patch but it is presented only for discussion purposes. There were some attempts to save 2PC in memory in past but it was rejected. Now, there might be the second round to discuss it.
With best regards,
Vitaly
Thank you for your interest in the discussion!
On Monday, February 26, 2024 16:24 MSK, Amit Kapila <amit.kapila16@gmail.com> wrote:
I think, the idea of async commit should be applied for both transactions: PREPARE and COMMIT PREPARED, which are actually two separate local transactions. For both these transactions we may call XLogSetAsyncXactLSN on commit instead of XLogFlush when async commit is enabled. When I use async commit, I mean to apply async commit to local transactions, not to a twophase (prepared) transaction itself.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?
The problem with reading WAL is due to async commit of PREPARE TRANSACTION which saves 2PC in the WAL. At the moment of COMMIT PREPARED the WAL with PREPARE TRANSACTION 2PC state may not be XLogFlush-ed yet. So, PREPARE TRANSACTION should wait until its 2PC state is flushed.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.
I did some experiments with saving 2PC state in the local memory of logical replication worker and, I think, it worked and demonstrated much better performance. Logical replication worker utilized up to 100% CPU. I'm just concerned about possible problems with async commit for twophase transactions.
To be more specific, I've attached a patch to support async commit for twophase. It is not the final patch but it is presented only for discussion purposes. There were some attempts to save 2PC in memory in past but it was rejected. Now, there might be the second round to discuss it.
With best regards,
Vitaly
Вложения
В списке pgsql-hackers по дате отправления: