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 CAA4eK1K39EQQPaOOhas_K+mxk_1zFosvEwxPtGY4TnEjheyuYw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow catchup of 2PC (twophase) transactions on replica in LR  (Давыдов Виталий <v.davydov@postgrespro.ru>)
Список pgsql-hackers
On Tue, Mar 5, 2024 at 7:59 PM Давыдов Виталий <v.davydov@postgrespro.ru> wrote:
>
> Thank you for the reply.
>
> On Tuesday, March 05, 2024 12:05 MSK, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
>
> In a nutshell, this changes PREPARE TRANSACTION so that if
> synchronous_commit is 'off', the PREPARE TRANSACTION is not fsync'd to
> disk. So if you crash after the PREPARE TRANSACTION has returned, the
> transaction might be lost. I think that's completely unacceptable.
>
>
> You are right, the prepared transaction might be lost after crash. The same may happen with regular transactions that
arenot fsync-ed on replica in logical replication by default. The subscription parameter synchronous_commit is OFF by
default.I'm not sure, is there some auto recovery for regular transactions? 
>

Unless the commit WAL is not flushed, we wouldn't have updated the
replication origin's LSN and neither the walsender would increase the
confirmed_flush_lsn for the corresponding slot till the commit is
flushed on subscriber. So, if the subscriber crashed before flushing
the commit record, server should send the same transaction again. The
same should be true for prepared transaction stuff as well.

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Stack overflow issue
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Combine Prune and Freeze records emitted by vacuum