Re: Autonomous Transaction (WIP) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Autonomous Transaction (WIP)
Date
Msg-id CAM-w4HM_PKxYCAgbD18B=1ycqudPMe-Unhx5+TYT6u=a6EgE8Q@mail.gmail.com
Whole thread Raw
In response to Autonomous Transaction (WIP)  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Responses Re: Autonomous Transaction (WIP)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Autonomous Transaction (WIP)  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
List pgsql-hackers
On Mon, Apr 7, 2014 at 12:06 AM, Rajeev rastogi
<rajeev.rastogi@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
requiredby lower autonomous transaction. If it happens so then deadlock will occur. So in order to solve this issue,
eachmain 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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Pending 9.4 patches
Next
From: Bruce Momjian
Date:
Subject: Re: [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0