On 31 July 2015 23:10, Robert Haas Wrote:
On Tue, Jul 28, 2015 at 6:01 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> That should be practical to special-case by maintaining a list of
>> parent transaction (virtual?) transaction IDs. Attempts to wait on a
>> lock held by any of those should fail immediately. There's no point
>> waiting for the deadlock detector since the outer tx can never
>> progress and commit/rollback to release locks, and it might not be
>> able to see the parent/child relationship from outside the backend
>> doing the nested tx anyway.
>I think we're going entirely down the wrong path here. Why is it ever useful for a backend's lock requests to
conflictwith themselves, even with autonomous transactions? That seems like an artifact of somebody else's
implementationthat we should be happy we don't need to copy.
IMHO, since most of the locking are managed at transaction level not backend level and we consider main & autonomous
transactionto be independent transaction, then practically they may conflict right.
It is also right as you said that there is no as such useful use-cases where autonomous transaction conflicts with main
(parent)transaction. But we cannot take it for granted as user might make a mistake. So at-least we should have some
mechanismto handle this rare case, for which as of now I think throwing error from autonomous transaction as one of the
solution.Once error thrown from autonomous transaction, main transaction may continue as it is (or abort main
transactionalso??).
Any other suggestion to handle this will be really helpful.
Thanks and Regards,
Kumar Rajeev Rastogi