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.
--
Craig Ringer 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
