> On 27 Mar 2017, at 16:29, Craig Ringer <craig@2ndquadrant.com> wrote:
>
> On 27 March 2017 at 17:53, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
>
>> I’m heavily underestimated amount of changes there, but almost finished
>> and will send updated patch in several hours.
>
> Oh, brilliant! Please post whatever you have before you knock off for
> the day anyway, even if it's just a WIP, so I can pick it up tomorrow
> my time and poke at its tests etc.
>
Ok, here it is.
Major differences comparing to previous version:
* GID is stored to commit/abort records only when wal_level >= logical.
* More consistency about storing and parsing origin info. Now it
is stored in prepare and abort records when repsession is active.
* Some clenup, function renames to get rid of xact_even/gid fields
in ReorderBuffer which i used only to copy them ReorderBufferTXN.
* Changed output plugin interface to one that was suggested upthread.
Now prepare/CP/AP is separate callback, and if none of them is set
then 2pc tx will be decoded as 1pc to provide back-compatibility.
* New callback filter_prepare() that can be used to switch between
1pc/2pc style of decoding 2pc tx.
* test_decoding uses new API and filters out aborted and running prepared tx.
It is actually easy to move unlock of 2PCState there to prepare callback to allow
decode of running tx, but since that extension is example ISTM that is better not to
hold that lock there during whole prepare decoding. However I leaved
enough information there about this and about case when that locks are not need at all
(when we are coordinating this tx).
Talking about locking of running prepared tx during decode, I think better solution
would be to use own custom lock here and register XACT_EVENT_PRE_ABORT
callback in extension to conflict with this lock. Decode should hold it in shared way,
while commit in excluseve. That will allow to lock stuff granularly ang block only
tx that is being decoded.
However we don’t have XACT_EVENT_PRE_ABORT, but it is several LOCs to
add it. Should I?
* It is actually doesn’t pass one of mine regression tests. I’ve added expected output
as it should be. I’ll try to send follow up message with fix, but right now sending it
as is, as you asked.
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company