From: Stas Kelvich <s.kelvich@postgrespro.ru>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Global snapshots
Date: Thu, 3 May 2018 20:11:26 +0300
Message-ID: <EDC74981-C4DD-4FA9-9E89-DFD659117149@postgrespro.ru> (raw)
In-Reply-To: <CAD21AoBph=12dbyH6KJJ--UkBKtzugT3iJb8CPL5fY7tdpLW8g@mail.gmail.com>
References: <21BC916B-80A1-43BF-8650-3363CCDAE09C@postgrespro.ru>
<CAD21AoBph=12dbyH6KJJ--UkBKtzugT3iJb8CPL5fY7tdpLW8g@mail.gmail.com>
> On 3 May 2018, at 18:28, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, May 2, 2018 at 1:27 AM, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
>> 1) To achieve commit atomicity of different nodes intermediate step is
>> introduced: at first running transaction is marked as InDoubt on all nodes,
>> and only after that each node commit it and stamps with a given GlobalCSN.
>> All readers who ran into tuples of an InDoubt transaction should wait until
>> it ends and recheck visibility.
>
> I'm concerned that long-running transaction could keep other
> transactions waiting and then the system gets stuck. Can this happen?
> and is there any workaround?
InDoubt state is set just before commit, so it is short-lived state.
During transaction execution global tx looks like an ordinary running
transaction. Failure during 2PC with coordinator not being able to
commit/abort this prepared transaction can result in situation where
InDoubt tuples will be locked for reading, but in such situation
coordinator should be blamed. Same problems will arise if prepared
transaction holds locks, for example.
--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The 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: s.kelvich@postgrespro.ru, sawada.mshk@gmail.com
Subject: Re: Global snapshots
In-Reply-To: <EDC74981-C4DD-4FA9-9E89-DFD659117149@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