Re: [HACKERS] logical decoding of two-phase transactions

From: Nikhil Sontakke <nikhils(at)2ndquadrant(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Sokolov Yura <y(dot)sokolov(at)postgrespro(dot)ru>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Date: 2018-04-05 09:17:30
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Hi Tomas,

> Uh? Simply rechecking if MyProc->decodeGroupLeader is NULL obviously
> does not fix the race condition - it might get NULL right after the
> check. So we need to either lookup the PROC again (and then get the
> associated lwlock), or hold some other type of lock.

I realized my approach was short-sighted while coding it up. So now we
lookup the leader pgproc, recheck if the XID is the same that we are
interested in and go ahead.

>>> 3) I don't quite understand why BecomeDecodeGroupMember does the
>>> cross-check using PID. In which case would it help?
>> When I wrote this support, I had written it with the intention of
>> supporting both 2PC (in which case pid is 0) and in-progress regular
>> transactions. That's why the presence of PID in these functions. The
>> current use case is just for 2PC, so we could remove it.
> Sure, but why do we need to cross-check the PID at all? I may be missing
> something here, but I don't see what does this protect against?

The fact that PID is 0 in case of prepared transactions was making me
nervous. So, I had added the assert that pid should only be 0 when
it's a prepared transaction and not otherwise. Anyways, since we are
dealing with only 2PC, I have removed the PID argument now. Also
removed is_prepared argument for the same reason.

>> Ok, I am looking at your provided patch and incorporating relevant
>> changes from it. WIll submit a patch set soon.
> OK.
PFA, latest patch set.

Nikhil Sontakke
PostgreSQL/Postgres-XL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
0001-Cleaning-up-of-flags-in-ReorderBufferTXN-structure.0504.patch application/octet-stream 7.3 KB
0002-Introduce-LogicalLockTransaction-LogicalUnlockTransa.0504.patch application/octet-stream 33.6 KB
0003-Support-decoding-of-two-phase-transactions-at-PREPAR.0504.patch application/octet-stream 43.3 KB
0004-Teach-test_decoding-plugin-to-work-with-2PC.0504.patch application/octet-stream 25.3 KB
0005-OPTIONAL-Additional-test-case-to-demonstrate-decoding-rollbac.0504.patch application/octet-stream 9.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-04-05 09:24:58 Re: [HACKERS] Add support for tuple routing to foreign partitions
Previous Message Magnus Hagander 2018-04-05 09:07:26 Re: Online enabling of checksums