From: Alexey Kondratov <a.kondratov@postgrespro.ru>
To: Bruce Momjian <bruce@momjian.us>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Andrey V. Lepikhov <a.lepikhov@postgrespro.ru>
Cc: tsunakawa.takay@fujitsu.com, movead.li@highgo.ca, 'Amit Kapila' <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Subject: Re: Global snapshots
Date: Mon, 21 Sep 2020 17:24:22 +0300
Message-ID: <3cdde64facc19a2c1baad1a3993a3b96@postgrespro.ru> (raw)
In-Reply-To: <20200917215432.GA24265@momjian.us>
References: <CA+fd4k6HE8xLGEvqWzABEg8kkju5MxU+if7bf-md0_2pjzXp9Q@mail.gmail.com>
<CAA4eK1+tMDXU9WtQ0kRgyk1jPr+K-7FowMdFB8=t-ptUEQa-mQ@mail.gmail.com>
<CA+fd4k6YTa25VxpsqvpvqZmsCErT5T8=MYNNDXt7Wn0DsJvSrg@mail.gmail.com>
<CAA4eK1KAB=YbvDd3a8g2qNj2QNrQANnrpNmoaNCtEMLfaiFjrg@mail.gmail.com>
<TYAPR01MB2990E83F9E886A9C8AB8E269FE760@TYAPR01MB2990.jpnprd01.prod.outlook.com>
<TYAPR01MB29902D8B671A5A6946F5AEA8FE720@TYAPR01MB2990.jpnprd01.prod.outlook.com>
<806c3708-26ea-b94d-87b1-d48e41e93726@postgrespro.ru>
<3ef7877bfed0582019eab3d462a43275@postgrespro.ru>
<057004b6-68bf-98ee-7c57-91c418f6e221@oss.nttdata.com>
<0e51d0298eed7588664e3c67a4fb15c9@postgrespro.ru>
<20200917215432.GA24265@momjian.us>
On 2020-09-18 00:54, Bruce Momjian wrote:
> On Tue, Sep 8, 2020 at 01:36:16PM +0300, Alexey Kondratov wrote:
>> Thank you for the link!
>>
>> After a quick look on the Sawada-san's patch set I think that there
>> are two
>> major differences:
>>
>> 1. There is a built-in foreign xacts resolver in the [1], which should
>> be
>> much more convenient from the end-user perspective. It involves huge
>> in-core
>> changes and additional complexity that is of course worth of.
>>
>> However, it's still not clear for me that it is possible to resolve
>> all
>> foreign prepared xacts on the Postgres' own side with a 100%
>> guarantee.
>> Imagine a situation when the coordinator node is actually a HA cluster
>> group
>> (primary + sync + async replica) and it failed just after PREPARE
>> stage of
>> after local COMMIT. In that case all foreign xacts will be left in the
>> prepared state. After failover process complete synchronous replica
>> will
>> become a new primary. Would it have all required info to properly
>> resolve
>> orphan prepared xacts?
>>
>> Probably, this situation is handled properly in the [1], but I've not
>> yet
>> finished a thorough reading of the patch set, though it has a great
>> doc!
>>
>> On the other hand, previous 0003 and my proposed patch rely on either
>> manual
>> resolution of hung prepared xacts or usage of external
>> monitor/resolver.
>> This approach is much simpler from the in-core perspective, but
>> doesn't look
>> as complete as [1] though.
>
> Have we considered how someone would clean up foreign transactions if
> the
> coordinating server dies? Could it be done manually? Would an
> external
> resolver, rather than an internal one, make this easier?
Both Sawada-san's patch [1] and in this thread (e.g. mine [2]) use 2PC
with a special gid format including a xid + server identification info.
Thus, one can select from pg_prepared_xacts, get xid and coordinator
info, then use txid_status() on the coordinator (or ex-coordinator) to
get transaction status and finally either commit or abort these stale
prepared xacts. Of course this could be wrapped into some user-level
support routines as it is done in the [1].
As for the benefits of using an external resolver, I think that there
are some of them from the whole system perspective:
1) If one follows the logic above, then this resolver could be
stateless, it takes all the required info from the Postgres nodes
themselves.
2) Then you can easily put it into container, which make it easier do
deploy to all these 'cloud' stuff like kubernetes.
3) Also you can scale resolvers independently from Postgres nodes.
I do not think that either of these points is a game changer, but we use
a very simple external resolver altogether with [2] in our sharding
prototype and it works just fine so far.
[1]
https://www.postgresql.org/message-id/CA%2Bfd4k4HOVqqC5QR4H984qvD0Ca9g%3D1oLYdrJT_18zP9t%2BUsJg%40ma...
[2]
https://www.postgresql.org/message-id/3ef7877bfed0582019eab3d462a43275%40postgrespro.ru
--
Alexey Kondratov
Postgres Professional https://www.postgrespro.com
Russian Postgres Company
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: a.kondratov@postgrespro.ru, bruce@momjian.us, masao.fujii@oss.nttdata.com, a.lepikhov@postgrespro.ru, amit.kapila16@gmail.com, masahiko.sawada@2ndquadrant.com
Subject: Re: Global snapshots
In-Reply-To: <3cdde64facc19a2c1baad1a3993a3b96@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox