Re: [HACKERS] logical decoding of two-phase transactions

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [HACKERS] logical decoding of two-phase transactions
Дата
Msg-id CAA4eK1LQCO9qhafw=s-yARwyLOq-479ZaRrfvLPEwH3Yvp-MwQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] logical decoding of two-phase transactions  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Tue, Jan 4, 2022 at 9:00 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> According to the doc, the two_phase field has:
>
> True if the slot is enabled for decoding prepared transactions. Always
> false for physical slots.
>
> It's unnatural a bit to me that replication slots have such a property
> since the replication slots have been used to protect WAL and tuples
> that are required for logical decoding, physical replication, and
> backup, etc from removal. Also, it seems that even if a replication
> slot is created with two_phase = off, it's overwritten to on if the
> plugin enables two-phase option. Is there any reason why we can turn
> on and off this value on the replication slot side and is there any
> use case where the replication slot’s two_phase is false and the
> plugin’s two-phase option is on and vice versa?
>

We enable two_phase only when we start streaming from the
subscriber-side. This is required because we can't enable it till the
initial sync is complete, otherwise, it could lead to loss of data.
See comments atop worker.c (description under the title: TWO_PHASE
TRANSACTIONS).

> I think that we can
> have replication slots always have two_phase_at value and remove the
> two_phase field from the view.
>

I am not sure how that will work because we can allow streaming of
prepared transactions when the same is enabled at the CREATE
SUBSCRIPTION time, the default for which is false.

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: GUC flags
Следующее
От: James Coleman
Дата:
Сообщение: Re: Consider parallel for lateral subqueries with limit