Re: StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

On 26 April 2017 at 15:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Nikhil Sontakke <nikhils(at)2ndquadrant(dot)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