On 18 August 2015 21:18, Robert Haas Wrote: >This footnote goes to my point. > >It seems clear to me that having the autonomous transaction "see" the >effects of the outer uncommitted transaction is a recipe for trouble. >If the autonomous transaction updates a row and commits, and the outer >transaction later aborts, the resulting state is inconsistent with any >serial history. I'm fairly certain that's going to leave us in an >unhappy place. > >Even more obviously, ending up with two committed row versions that are >both updates of a single ancestor version is no good. > >So, I agree that this scenario should be an error. What I don't agree >with is the idea that it should be the deadlock detector's job to throw >that error. Rather, I think that when we examine the xmax of the tuple >we can see - which is the original one, not the one updated by the outer >transaction - we should check whether that XID belongs to an outer >transaction. If it does, we should throw an error instead of trying to >lock it. That way (1) the error message will be clear and specific to >the situation and (2) we don't need a separate PGPROC for each >autonomous transaction. The first of those benefits is agreeable; the >second one is, in my opinion, a key design goal for this feature.
Yes I agree with this. I was in favor of error all the time without involving deadlock detector. Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers