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.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: