On 01/03/17 10:24, Craig Ringer wrote:
> On 9 February 2017 at 21:23, Stas Kelvich <s.kelv...@postgrespro.ru> wrote:
>
>>> On 2 Feb 2017, at 00:35, Craig Ringer <cr...@2ndquadrant.com> wrote:
>>>
>>> Stas was concerned about what happens in logical decoding if we crash
>>> between PREPSRE TRANSACTION and COMMIT PREPARED. But we'll always go back
>>> and decode the whole txn again anyway so it doesn't matter.
>>
>> Not exactly. It seems that in previous discussions we were not on the same
>> page, probably due to unclear arguments by me.
>>
>> From my point of view there is no problems (or at least new problems
>> comparing to ordinary 2PC) with preparing transactions on slave servers with
>> something like “#{xid}#{node_id}” instead of GID if issuing node is
>> coordinator of that transaction. In case of failure, restart, crash we have
>> the same options about deciding what to do with uncommitted transactions.
>
> But we don't *need* to do that. We have access to the GID of the 2PC
> xact from PREPARE TRANSACTION until COMMIT PREPARED, after which we
> have no need for it. So we can always use the user-supplied GID.
>
>> I performed some tests to understand real impact on size of WAL. I've
>> compared postgres -master with wal_level = logical, after 3M 2PC
>> transactions with patched postgres where GID’s are stored inside commit
>> record too.
>
> Why do you do this? You don't need to. You can look the GID up from
> the 2pc status table in memory unless the master already did COMMIT
> PREPARED, in which case you can just decode it as a normal xact as if
> it were never 2pc in the first place.
>
> I don't think I've managed to make this point by description, so I'll
> try to modify your patch to demonstrate.
>
If I understand you correctly you are saying that if PREPARE is being
decoded, we can load the GID from the 2pc info in memory about the
specific 2pc. The info gets removed on COMMIT PREPARED but at that point
there is no real difference between replicating it as 2pc or 1pc since
the 2pc behavior is for all intents and purposes lost at that point.
Works for me. I guess the hard part is knowing if COMMIT PREPARED
happened at the time PREPARE is decoded, but I existence of the needed
info could be probably be used for that.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
