Re: out-of-order XID insertion in KnownAssignedXids - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: out-of-order XID insertion in KnownAssignedXids
Date
Msg-id 20181009075258.GI2137@paquier.xyz
Whole thread Raw
In response to Re: out-of-order XID insertion in KnownAssignedXids  (Michael Paquier <michael@paquier.xyz>)
Responses Re: out-of-order XID insertion in KnownAssignedXids  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
On Tue, Oct 09, 2018 at 02:59:00PM +0900, Michael Paquier wrote:
> +1.  I am looking at how to make that possible.

And so...  Going through a bit of investigation the problem is that each
2PC transaction preparing finishes by putting the procarray in a state
where there are two entries referring to the same transaction running as
MarkAsPrepared adds an extra entry on the top of the one already
existing.  This is expected though per the comments in
ProcArrayClearTransaction(), as it assumes that MyProc can be safely
cleaned and it assumes that there is a duplicated entry.  Then,
GetRunningTransactionData() ignores the assumption that those duplicate
entries can exist, which makes the snapshot data taken as incorrect,
generating those incorrect XLOG_RUNNING_XACT records.

The most simple fix I can think of first is to tweak the origin of the
problem in GetRunningTransactionData() so as those duplicate XIDs are
ignored if found as there has to be a state between the time
MarkAsPrepared() inserted the 2PC entry in the procarray and the time
ProcArrayClearTransaction() gets called.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: executor relation handling
Next
From: Amit Langote
Date:
Subject: Re: executor relation handling