On 31 July 2015 23:10, Robert Haas Wrote: On Tue, Jul 28, 2015 at 6:01 AM, Craig Ringer <cr...@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 conflict with themselves, even with >autonomous transactions? That seems like an artifact of somebody else's >implementation that 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 transaction to 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 mechanism to 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 transaction also??). Any other suggestion to handle this will be really helpful. 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
