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
