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

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: [HACKERS] logical decoding of two-phase transactions
Дата
Msg-id CAD21AoCqjYL1ZxOz6smcVvnge6jw9uG38-rHXU+LfvnovQ0tFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] logical decoding of two-phase transactions  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Wed, Dec 16, 2020 at 6:22 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Dec 16, 2020 at 1:04 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > Thank you for updating the patch. I have two questions:
> >
> > -----
> > @@ -239,6 +239,19 @@ CREATE SUBSCRIPTION <replaceable
> > class="parameter">subscription_name</replaceabl
> >           </para>
> >          </listitem>
> >         </varlistentry>
> > +       <varlistentry>
> > +        <term><literal>two_phase</literal> (<type>boolean</type>)</term>
> > +        <listitem>
> > +         <para>
> > +          Specifies whether two-phase commit is enabled for this subscription.
> > +          The default is <literal>false</literal>.
> > +          When two-phase commit is enabled then the decoded
> > transactions are sent
> > +          to the subscriber on the PREPARE TRANSACTION. When
> > two-phase commit is not
> > +          enabled then PREPARE TRANSACTION and COMMIT/ROLLBACK PREPARED are not
> > +          decoded on the publisher.
> > +         </para>
> > +        </listitem>
> > +       </varlistentry>
> >
> > The user will need to specify the 'two_phase’ option on CREATE
> > SUBSCRIPTION. It would mean the user will need to control what data is
> > streamed both on publication side for INSERT/UPDATE/DELETE/TRUNCATE
> > and on subscriber side for PREPARE. Looking at the implementation of
> > the ’two_phase’ option of CREATE SUBSCRIPTION, it ultimately just
> > passes the ‘two_phase' option to the publisher. Why don’t we set it on
> > the publisher side?
> >
>
> There could be multiple subscriptions for the same publication, some
> want to decode the transaction at prepare time and others might want
> to decode at commit time only.  Also, one subscription could subscribe
> to multiple publications, so not sure if it is even feasible to set at
> publication level (consider one txn has changes belonging to multiple
> publications). This option controls how the data is streamed from a
> publication similar to other options like 'streaming'. Why do you
> think this should be any different?

Oh, I was thinking that the option controls what data is streamed
similar to the 'publish' option. But I agreed with you. As you
mentioned, it might be a problem if a subscription subscribes multiple
publications setting different ’two_phase’ options. Also in terms of
changing this option while streaming changes, it’s better to control
it on the subscriber side.

Regards,

--
Masahiko Sawada
EnterpriseDB:  https://www.enterprisedb.com/



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: On login trigger: take three
Следующее
От: Önder Kalacı
Дата:
Сообщение: Re: row filtering for logical replication