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 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
