From: Bruce Momjian <bruce@momjian.us>
To: Alexey Kondratov <a.kondratov@postgrespro.ru>
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: Thu, 17 Sep 2020 17:54:32 -0400
Message-ID: <20200917215432.GA24265@momjian.us> (raw)
In-Reply-To: <0e51d0298eed7588664e3c67a4fb15c9@postgrespro.ru>
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>
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?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
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: bruce@momjian.us, a.kondratov@postgrespro.ru, masao.fujii@oss.nttdata.com, a.lepikhov@postgrespro.ru, amit.kapila16@gmail.com, masahiko.sawada@2ndquadrant.com
Subject: Re: Global snapshots
In-Reply-To: <20200917215432.GA24265@momjian.us>
* 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