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

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Ajin Cherian <itsajin(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Date: 2020-12-17 06:43:11
Message-ID: CAD21AoCqjYL1ZxOz6smcVvnge6jw9uG38-rHXU+LfvnovQ0tFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 16, 2020 at 6:22 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Dec 16, 2020 at 1:04 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Önder Kalacı 2020-12-17 06:43:30 Re: row filtering for logical replication
Previous Message Pavel Stehule 2020-12-17 06:31:45 Re: On login trigger: take three