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 14:53:11 |
Message-ID: | CAMGcDxeW2xE51Rx8V8hwL7YMkVFBwtOwDco5=opWd-YACJMi0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
>> 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.
>
I did some more gdb single-stepping and debugging on this. Introduced a few
more fetch pgproc using XID calls for more robustness. I am satisfied now from
my point of view with the decodegroup lock changes.
Also a few other changes related to cleanups and setting of the txn flags at
all places.
PFA, v2.0 of the patchset for today.
"make check-world" passes ok on these patches.
Regards,
Nikhils
>>
>>>>
>>>> 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.
>
> Regards,
> Nikhils
> --
> Nikhil Sontakke http://www.2ndQuadrant.com/
> PostgreSQL/Postgres-XL Development, 24x7 Support, Training & Services
--
Nikhil Sontakke http://www.2ndQuadrant.com/
PostgreSQL/Postgres-XL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Cleaning-up-of-flags-in-ReorderBufferTXN-structure.0504.v2.0.patch | application/octet-stream | 7.3 KB |
0002-Introduce-LogicalLockTransaction-LogicalUnlockTransa.0504.v2.0.patch | application/octet-stream | 33.9 KB |
0003-Support-decoding-of-two-phase-transactions-at-PREPAR.0504.v2.0.patch | application/octet-stream | 43.6 KB |
0004-Teach-test_decoding-plugin-to-work-with-2PC.0504.v2.0.patch | application/octet-stream | 25.3 KB |
0005-OPTIONAL-Additional-test-case-to-demonstrate-decoding-rollbac.0504.v2.0.patch | application/octet-stream | 9.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2018-04-05 14:55:22 | Re: Online enabling of checksums |
Previous Message | John Naylor | 2018-04-05 14:49:28 | Re: WIP: a way forward on bootstrap data |