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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
