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

On 04/14/2014 07:51 PM, Tom Lane wrote:
> I'd prefer to leave the prepare sequence alone and instead find a way
> to reject COMMIT PREPARED until after the source transaction is safely
> clear of the race conditions.  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.

Hmm. What if one of the post-cleanup action fails? We can't bail out of 
the prepare sequence until we have transfered the locks to the new 
PGPROC. Otherwise the locks are lost. In essence, there should be a 
critical section from the EndPrepare call until all the critical cleanup 
actions like PostPrepare_Locks have been done, and I don't think we want 
that. We might be able to guarantee that the built-in post-cleanup 
operations are safe enough for that, but there's also CallXactCallbacks 
in there.

Given the lack of reports of that happening, though, perhaps that's not 
an issue.

- Heikki