Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: Problem with txid_snapshot_in/out() functionality)

On 2014-04-14 12:51:02 -0400, Tom Lane wrote:
> The whole thing feels like we are solving the wrong problem, anyway.
> IIUC, the complaint arises because we are allowing COMMIT PREPARED
> to occur before the source transaction has reported successful prepare
> to its client.  Surely that does not need to be a legal case?  No
> correctly-operating 2PC xact manager would do that.

I agree here. This seems somewhat risky, just to support a case that
shouldn't happen in reality - as somewhat evidenced by the fact that
there don't seem to be field reports around this.

> The upthread idea of looking at vxid
> instead of xid might help, except that I see we clear both of them
> in ProcArrayClearTransaction.  We'd need some state in PGPROC that
> isn't cleared till later than that.

I wonder if the most natural way to express this wouldn't be to have a
heavyweight lock for every 2pc xact
'slot'. ResourceOwnerRelease(RESOURCE_RELEASE_LOCKS) should be scheduled
correctly to make error handling for this work.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services