Re: Problem with txid_snapshot_in/out() functionality - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problem with txid_snapshot_in/out() functionality
Date
Msg-id 25392.1397310444@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with txid_snapshot_in/out() functionality  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Problem with txid_snapshot_in/out() functionality  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 04/12/2014 12:07 AM, Jan Wieck wrote:
>> the Slony team has been getting seldom reports of a problem with the
>> txid_snapshot data type.
>> The symptom is that a txid_snapshot on output lists the same txid
>> multiple times in the xip list part of the external representation.

> It's two-phase commit. When preparing a transaction, the state of the 
> transaction is first transfered to a dummy PGXACT entry, and then the 
> PGXACT entry of the backend is cleared. There is a transient state when 
> both PGXACT entries have the same xid.

Hm, yeah, but why is that intermediate state visible to anyone else?
Don't we have exclusive lock on the PGPROC array while we're doing this?
If we don't, aren't we letting other backends see non-self-consistent
state in regards to who holds which locks, for example?

I'm worried that the proposed fix is just band-aiding one particular
symptom of inadequate locking.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Problem with txid_snapshot_in/out() functionality
Next
From: Andres Freund
Date:
Subject: Re: Problem with txid_snapshot_in/out() functionality