Re: [HACKERS] logical decoding of two-phase transactions - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] logical decoding of two-phase transactions
Date
Msg-id CAMsr+YHVNW-Lh-XnYnkfhGL2QT8kK9kM4zkZ4+Sv=fszhujj-g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical decoding of two-phase transactions  (Stas Kelvich <s.kelvich@postgrespro.ru>)
Responses Re: [HACKERS] logical decoding of two-phase transactions  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
On 9 February 2017 at 21:23, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:

>> On 2 Feb 2017, at 00:35, Craig Ringer <craig@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
transactionson slave servers with something like “#{xid}#{node_id}” instead of GID if issuing node is coordinator of
thattransaction. 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Write Ahead Logging for Hash Indexes
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)