Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
Date
Msg-id CANP8+jKDkG8J3ZKpqhUhJ8-k+ns0m-UYai3FwnRupp=EL_DKUg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly
List pgsql-hackers
On 26 April 2017 at 15:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Nikhil Sontakke <nikhils@2ndquadrant.com> writes:
>> A SELECT query on the newly promoted master on any of the tables involved
>> in the 2PC hangs. The hang is due to a loop in
>> SubTransGetTopmostTransaction(). Due to incorrect linkages, we get a
>> circular reference in parentxid <-> subxid inducing the infinite loop.
>
> I'm inclined to propose that
>
> (1) SubTransSetParent should contain an assert that
>         Assert(TransactionIdFollows(xid, parent));
> There is a similar assertion near one of the call sites, but that's
> obviously too far away from the action.
>
> (2) SubTransGetTopmostTransaction ought to contain an actual runtime
> test and ereport (not just Assert) that the parent XID it got from
> pg_subtrans precedes the child XID that was looked up.  This would
> protect us against similar infinite loops in the future.  Even without
> bugs, such a loop could arise due to corrupted data.

Pretty much what I was thinking.


I've added code following Michael and Tom's comments to the previous
patch. New patch attached.

Passes with and without Nikhil's new test.

I plan to apply both patches tomorrow morning my time to give time for
further comments.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: [HACKERS] Logical replication in the same cluster
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] scram and \password