Re: Autonomous Transaction (WIP)

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Autonomous Transaction (WIP)
Дата
Msg-id CAM-w4HM_PKxYCAgbD18B=1ycqudPMe-Unhx5+TYT6u=a6EgE8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Autonomous Transaction (WIP)  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Ответы Re: Autonomous Transaction (WIP)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Autonomous Transaction (WIP)  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Pending 9.4 patches
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0