> 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