[prev in list] [next in list] [prev in thread] [next in thread]
List: pgsql-hackers
Subject: Re: [HACKERS] Autonomous Transaction is back
From: Robert Haas <robertmhaas () gmail ! com>
Date: 2015-07-31 17:40:14
Message-ID: CA+Tgmoa=fU9Pk0cr2f6FJzEEnEX8usttkfeJ7D=5RZW0ri+8ZQ () mail ! gmail ! com
[Download RAW message or body]
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic