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

From Michael Paquier
Subject Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
Date
Msg-id CAB7nPqT-ki3Z=gJHcFzp=8U+26GAYgF_uw3ALycjJTDpqdebeg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Apr 27, 2017 at 2:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
>> I've added code following Michael and Tom's comments to the previous
>> patch. New patch attached.
>
> Couple of minor suggestions:
>
> * Rather than deleting the comment for SubTransSetParent entirely,
> maybe make it say "It's possible that the parent was already recorded.
> However, we should never be asked to change an already-set entry to
> something else."
>
> * In SubTransGetTopmostTransaction, maybe it'd be better to spell
> "TransactionIdFollowsOrEquals" as "!TransactionIdPrecedes" to make
> it look more like the test just above.  Matter of taste though.
>
> * Less a matter of taste is that I think that should be just elog(ERROR);
> there's no good reason to make it FATAL.
>
> * Also, I think there should be a comment there, along the lines of
> "check for reversed linkage to ensure this isn't an infinite loop".

No more comments from here, thanks for working on the patch.
-- 
Michael



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] identity columns
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] PG 10 release notes