Re: Autonomous Transaction (WIP)

Поиск
Список
Период
Сортировка
От Rajeev rastogi
Тема Re: Autonomous Transaction (WIP)
Дата
Msg-id BF2827DCCE55594C8D7A8F7FFD3AB7713DDDFC06@SZXEML508-MBX.china.huawei.com
обсуждение исходный текст
Ответ на Re: Autonomous Transaction (WIP)  (Greg Stark <stark@mit.edu>)
Ответы Re: Autonomous Transaction (WIP)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 08 April 2014 23:29, Greg Stark Wrote:

> 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.

No, I am not creating a separate procarray entry to maintain autonomous transaction.

Similar to MyPgXact (of type PGXACT), which hold main transaction for a particular session,
I have created another member MyPgAutonomousXact (of type structure PGAutonomousXACT),
which holds autonomous transactions for a particular session.

Unlike MyPgXact, MyPgAutonomousXact will be an array to hold multiple autonomous transactions.
There are no limit, other than resource limits, on how many levels of autonomous transaction
can be started. As of now we have used maximum as 3, which can be changed easily if required or
it can be made configurable also.

MyProc for a particular session just have an entry to track the level of autonomous transaction,
which will be used to reference current autonomous transaction from MyPgAutonomousXact.
e.g. if one autonomous transaction is created and it is currently working under this transaction,
then level inside MyProc will be as 1. Once this transaction is over and popped out, level will
be reduced to zero.

Again like main transaction MyPgXact, MyPgAutonomousXact can also track list of all sub-transaction
and overflowed transaction started within this autonomous transaction.

> > Deadlock Detection:
> I'm not sure how this would work out internally
In order to resolve deadlock, two member variable will be created in the structure PROLOCK:
    Bitmask for lock types currently held by autonomous transaction.
        LOCKMASK    holdMaskByAutoTx[MAX_AUTO_TX_LEVEL]
    Bitmask for lock types currently held by main transaction.
        LOCKMASK    holdMaskByNormalTx

Now when we grant the lock to particular transaction, depending on type of transaction, bit
Mask will be set for either holdMaskByAutoTx or holdMaskByNormalTx.
Similar when lock is ungranted, corresponding bitmask will be reset.

Using the above two information, deadlock will be detected.

Any comment/feedback/doubt are welcome.

Thanks and Regards,
Kumar Rajeev Rastogi





Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [DOCS] Call for GIST/GIN/SP-GIST opclass documentation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: psql \d+ and oid display