Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: logical decoding of two-phase transactions
From: Stas Kelvich <s.kelvich@postgrespro.ru>
In-Reply-To: <20170327212528.cwf4aotytwrsowwx@alap3.anarazel.de>
Date: Tue, 28 Mar 2017 04:12:41 +0300
Cc: 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: <A434797D-1283-42C5-8CE5-7F1CD0B68F36@postgrespro.ru>
References: <E6112EA9-2949-4E4A-8FE4-1C6A2096379D@postgrespro.ru>
 <CAMsr+YFsN5D=dPjoyXN33OBTGJgfYn3rrh-BH3GX5Qfbg-3VRA@mail.gmail.com>
 <EFF3D2BF-05BD-4EBA-A254-27EED342CD22@postgrespro.ru>
 <CAMsr+YHwPAeMrD2HEnQFy5dQr8CR=fwVjnokZNFua_K+QmMhBA@mail.gmail.com>
 <F5187EFB-8907-4D73-B961-9AC8B45B03CD@postgrespro.ru>
 <CAMsr+YGkEtwcsvQSU_6w2hnoY=oGEAxdK_ApYs3e-iwqSm06qg@mail.gmail.com>
 <CAMsr+YF0FDNjstkKzByeyG3G66SWf_mbH+cr3qhKAK3UYaZzaA@mail.gmail.com>
 <DFC9E270-4554-4E46-B2F8-FD864C29610D@postgrespro.ru>
 <CAMsr+YGm-pft3CtxbzP0SOFj6rN62Loh43hj2oYjuYCVbDLXFg@mail.gmail.com>
 <1A2E98FB-7705-43A0-B625-3F55A8FFE5D1@postgrespro.ru>
 <20170327212528.cwf4aotytwrsowwx@alap3.anarazel.de>
To: Andres Freund <andres@anarazel.de>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> On 28 Mar 2017, at 00:25, Andres Freund <andres@anarazel.de> wrote:
>=20
> Hi,
>=20
> On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote:
>> Ok, here it is.
>=20
> On a very quick skim, this doesn't seem to solve the issues around
> deadlocks of prepared transactions vs. catalog tables.  What if the
> prepared transaction contains something like LOCK pg_class; (there's a
> lot more realistic examples)? Then decoding won't be able to continue,
> until that transaction is committed / aborted?

But why is that deadlock? Seems as just lock.

In case of prepared lock of pg_class decoding will wait until it committed =
and
then continue to decode. As well as anything in postgres that accesses pg_c=
lass,
including inability to connect to database and bricking database if you acc=
identally
disconnected before committing that tx (as you showed me some while ago :-).

IMO it is issue of being able to prepare such lock, than of decoding.

Is there any other scenarios where catalog readers are blocked except expli=
cit lock
on catalog table? Alters on catalogs seems to be prohibited.

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