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