Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: logical decoding of two-phase transactions
From: Stas Kelvich <s.kelvich@postgrespro.ru>
In-Reply-To: 
 <CAMGcDxfBkghqK94VZoOBE4XaOA9xZmkaM-opKeEzOrPmajVHBA@mail.gmail.com>
Date: Wed, 27 Sep 2017 14:46:23 +0300
Cc: Dmitry Dolgov <9erthalion6@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>,
 Masahiko Sawada <sawada.mshk@gmail.com>,
 Simon Riggs <simon@2ndquadrant.com>,
 Craig Ringer <craig@2ndquadrant.com>,
 Petr Jelinek <petr.jelinek@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6F3575D-BA17-43AB-A75F-12934885BADB@postgrespro.ru>
References: <A434797D-1283-42C5-8CE5-7F1CD0B68F36@postgrespro.ru>
 <20170328012546.473psm6546bgsi2c@alap3.anarazel.de>
 <CAMsr+YF9ya3PsyWekqBqaeRz9WC+roGWGY5qDso0Jx6O1ajAHQ@mail.gmail.com>
 <CANP8+j+TMef2sWxiiWzpm8oFR7SvNArbOW2xqmJjKeLB7UhL8Q@mail.gmail.com>
 <20170328143840.b7qdvqh3uh74f2oa@alap3.anarazel.de>
 <CANP8+jLhUR=q+xPR4RKjJr6vaU+976kKmwipdjhU6VB+jR_ROg@mail.gmail.com>
 <20170328150823.u4he7rbd72mzeydl@alap3.anarazel.de>
 <E38B1BB4-4A66-44E9-B764-8C83E424174B@postgrespro.ru>
 <CAD21AoDDC7USpUyUim=7BwuFByauRGfLzkE7hhiV=jjDckc+KA@mail.gmail.com>
 <9CD693AF-51BE-4A19-9D26-16031CDAD9C9@postgrespro.ru>
 <20170404173133.olo7keeh3dzhriay@alap3.anarazel.de>
 <CA+q6zcUJLTwammygSSp0=evX_Ns46b2JkvWu214jbM-15xc_MA@mail.gmail.com>
 <19307.1494706954@sss.pgh.pa.us>
 <CA+q6zcX7m3aB5ziVA4D8oGRbtMJcaKXKZO6SEWVZ3hOZv7mQWQ@mail.gmail.com>
 <CAMGcDxfBkghqK94VZoOBE4XaOA9xZmkaM-opKeEzOrPmajVHBA@mail.gmail.com>
To: Nikhil Sontakke <nikhils@2ndquadrant.com>,
 Andres Freund <andres@anarazel.de>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> On 7 Sep 2017, at 18:58, Nikhil Sontakke <nikhils@2ndquadrant.com> wrote:
>=20
> Hi,
>=20
> FYI all, wanted to mention that I am working on an updated version of
> the latest patch that I plan to submit to a later CF.
>=20

Cool!

So what kind of architecture do you have in mind? Same way as is it was imp=
lemented before?
As far as I remember there were two main issues:

* Decodong of aborted prepared transaction.

If such transaction modified catalog then we can=E2=80=99t read reliable in=
fo with our historic snapshot,
since clog already have aborted bit for our tx it will brake visibility log=
ic. There are some way to
deal with that =E2=80=94 by doing catalog seq scan two times and counting n=
umber of tuples (details
upthread) or by hijacking clog values in historic visibility function. But =
ISTM it is better not solve this
issue at all =3D) In most cases intended usage of decoding of 2PC transacti=
on is to do some form
of distributed commit, so naturally decoding will happens only with in-prog=
ress transactions and
we commit/abort will happen only after it is decoded, sent and response is =
received. So we can
just have atomic flag that prevents commit/abort of tx currently being deco=
ded. And we can filter
interesting prepared transactions based on GID, to prevent holding this loc=
k for ordinary 2pc.

* Possible deadlocks that Andres was talking about.

I spend some time trying to find that, but didn=E2=80=99t find any. If lock=
ing pg_class in prepared tx is the only
example then (imho) it is better to just forbid to prepare such transaction=
s. Otherwise if some realistic
examples that can block decoding are actually exist, then we probably need =
to reconsider the way
tx being decoded. Anyway this part probably need Andres blessing.


Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers