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
