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/
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 |