On 23 July 2015 at 13:31, Rajeev rastogi <rajeev.rastogi@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
