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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
