Re: Autonomous Transaction (WIP)

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Autonomous Transaction (WIP)
Date: 2014-04-09 04:24:04
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DDDFC06@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
autonomous_tx_v1.patch application/octet-stream 109.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-09 05:02:05 Re: psql \d+ and oid display
Previous Message Robert Haas 2014-04-09 04:23:43 Re: Call for GIST/GIN/SP-GIST opclass documentation