Re: Slow catchup of 2PC (twophase) transactions on replica in LR

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Slow catchup of 2PC (twophase) transactions on replica in LR
Дата
Msg-id CAA4eK1J6wOMkDDt3iOs+JqkvQvuwSORosTpqdejgvXqFmxex=A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow catchup of 2PC (twophase) transactions on replica in LR  (Давыдов Виталий <v.davydov@postgrespro.ru>)
Ответы Re: Slow catchup of 2PC (twophase) transactions on replica in LR  (Давыдов Виталий <v.davydov@postgrespro.ru>)
Список pgsql-hackers
On Tue, Feb 27, 2024 at 4:49 PM Давыдов Виталий
<v.davydov@postgrespro.ru> wrote:
>
> 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 reason is probably that when the WAL record for prepared is already flushed then what will be the idea of
asynccommit here? 
>
> I think, the idea of async commit should be applied for both transactions: PREPARE and COMMIT PREPARED, which are
actuallytwo separate local transactions. For both these transactions we may call XLogSetAsyncXactLSN on commit instead
ofXLogFlush when async commit is enabled. When I use async commit, I mean to apply async commit to local transactions,
notto a twophase (prepared) transaction itself. 
>
>
> 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
witha flush of commit_prepared or reading WAL for prepared or both of these. 
>
> The problem with reading WAL is due to async commit of PREPARE TRANSACTION which saves 2PC in the WAL. At the moment
ofCOMMIT PREPARED the WAL with PREPARE TRANSACTION 2PC state may not be XLogFlush-ed yet. 
>

As we do XLogFlush() at the time of prepare then why it is not
available? OR are you talking about this state after your idea/patch
where you are trying to make both Prepare and Commit_prepared records
async?

 So, PREPARE TRANSACTION should wait until its 2PC state is flushed.
>
> I did some experiments with saving 2PC state in the local memory of logical replication worker and, I think, it
workedand demonstrated much better performance. Logical replication worker utilized up to 100% CPU. I'm just concerned
aboutpossible 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
presentedonly for discussion purposes. There were some attempts to save 2PC in memory in past but it was rejected. 
>

It would be good if you could link those threads.

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445)
Следующее
От: Jeevan Chalke
Дата:
Сообщение: Re: More new SQL/JSON item methods