Re: Autonomous Transaction is back
От | Robert Haas |
---|---|
Тема | Re: Autonomous Transaction is back |
Дата | |
Msg-id | CA+Tgmoa=fU9Pk0cr2f6FJzEEnEX8usttkfeJ7D=5RZW0ri+8ZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Autonomous Transaction is back (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Autonomous Transaction is back
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: