On Mon, Apr 7, 2014 at 12:06 AM, Rajeev rastogi <rajeev.rast...@huawei.com> wrote: > > Deadlock Detection: > > It is possible that the main or upper autonomous transaction has taken a lock > on some resource, which might be required by lower autonomous transaction. If > it happens so then deadlock will occur. So in order to solve this issue, each > main and autonomous transaction will hold list of all locks acquired in > PROLOCK based on which deadlock will be resolved.
I'm not sure how this would work out internally -- it would depend on how you plan to allocate the new transaction in the internal data structures -- but the natural way to prevent/detect deadlocks would be to have the parent transaction immediately take a lock on the autonomous transaction as soon as it's started. That would cause any lock in the autonomous transaction which caused it to wait on the parent transaction to be detected as a deadlock. It would also cause any monitoring tool to correctly show the parent transaction as waiting on the autonomous transaction to finish. If the autonomous transaction is actually a separate procarray entry (which I suspect it would have to be, much like prepared transactions and the dblink connections which are commonly used to kludge autonomous transactions) then this should be fairly painless. If you implement some kind of saving and restoring procarray data then it probably wouldn't work out. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
