> On 3 May 2018, at 18:28, Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Wed, May 2, 2018 at 1:27 AM, Stas Kelvich <s.kelv...@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
