On 23 July 2015 at 13:31, Rajeev rastogi <rajeev.rast...@huawei.com> wrote:
> 1. The autonomous transaction treated as a completely different > transaction from the master transaction. Personally I think that's a lot more useful than having the inner tx able to see the outer tx's uncommitted changes. > 2. It should be allowed to deadlock with master transaction. We > need to work-out a solution to avoid deadlock. The deadlock case in autonomous tx's is a bit different. Assuming you don't intend to allow interleaving, where you can switch between transactions at will rather than just at begin/commit, the only way a deadlock can happen is when the outer tx holds a lock that the inner tx tries to acquire. 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. There's no need to check the parent list until we actually try to wait on a lock, though I don't know whether it's practical to delay until then. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
