Re: logical decoding of two-phase transactions

On 20 March 2017 at 21:47, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
>
>> On 20 Mar 2017, at 16:39, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>>
>> On 20 March 2017 at 20:57, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
>>>
>>>> On 20 Mar 2017, at 15:17, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>>>>
>>>>> I thought about having special field (or reusing one of the existing fields)
>>>>> in snapshot struct to force filtering xmax > snap->xmax or xmin = snap->xmin
>>>>> as Petr suggested. Then this logic can reside in ReorderBufferCommit().
>>>>> However this is not solving problem with catcache, so I'm looking into it right now.
>>>>
>>>> OK, so this is only an issue if we have xacts that change the schema
>>>> of tables and also insert/update/delete to their heaps. Right?
>>>>
>>>> So, given that this is CF3 for Pg10, should we take a step back and
>>>> impose the limitation that we can decode 2PC with schema changes or
>>>> data row changes, but not both?
>>>
>>> Yep, time is tight. I’ll try today/tomorrow to proceed with this two scan approach.
>>> If I’ll fail to do that during this time then I’ll just update this patch to decode
>>> only non-ddl 2pc transactions as you suggested.
>>
>> I wasn't suggesting not decoding them, but giving the plugin the
>> option of whether to proceed with decoding or not.
>>
>> As Simon said, have a pre-decode-prepared callback that lets the
>> plugin get a lock on the 2pc xact if it wants, or say it doesn't want
>> to decode it until it commits.
>>
>> That'd be useful anyway, so we can filter and only do decoding at
>> prepare transaction time of xacts the downstream wants to know about
>> before they commit.
>
> Ah, got that. Okay.

Any news here?

We're in the last week of the CF. If you have a patch that's nearly
ready or getting there, now would be a good time to post it for help
and input from others.

I would really like to get this in, but we're running out of time.

Even if you just post your snapshot management work, with the cosmetic
changes discussed above, that would be a valuable start.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services