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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to