On 10 April 2014 11:18, Pavan Deolasee Wrote:
>>I could think of few global variables like transaction properties
>>related(i.e. read-only mode, isolation level etc). As I plan to keep
>>transaction properties of autonomous transaction same as main transaction, so
>>there is no need to have these global variables separately.
>>Apart from this there are global variables like with-in transaction counters,
>>GUC, xactStartTimeStamp. I think there is no need to maintain these variables
>>also separately. They can continue from previous value for autonomous
>>transaction also similar to as sub->>transaction does.
>Hmm. Is that in line with what other databases do ? I would have preferred AT
>to run like a standalone transaction without any influence of the starting
>transaction, managing its own resources/locks/visibility/triggers etc.
To me it seems it is not very useful to keep the transaction properties
separate except the read-only properties (though oracle does not share any
So we can have restriction that isolation and deferrable properties of main
transaction will be inherited by autonomous transaction but read-only
properties can be defined independently by autonomous transaction. Which looks
to be fair restriction according to me.
In order to keep read-only properties separate, there is already infrastructure
in PG. Inside the structure TransactionStateData, there is variable
prevXactReadOnly (entry-time xact r/o state), which can keep the parent
transaction read only properties and XactReadOnly can be changed to current
Moreover we can take this (transaction
properties) as a feature enhancement also once a basic infrastructure is
established, if acceptable to everyone.
Autonomous transaction will not share resource/lock/visibility etc with main
transaction. This has been already taken care in WIP patch.
>>In-case of autonomous transaction, only specific global variables initialized
>>are related to resources (similar to sub-transaction), which anyway gets
>>stored in current transaction state.
>>Please let me know if I am missing something or if you have some specific
>>global variables related issue.
>No, I don't have any specific issues in mind. Mostly all such global state is
>managed through various AtStart/AtEOX and related routines. So a careful
>examination of all those routines will give a good idea what needs to be
>handled. You probably will require to write
>AtATStart/AtATEOX and similar routines to manage the state at AT
>start/commit/rollback. Sorry, I haven't looked at your WIP patch yet.
For some of the resources, I have already written AtATStart/AtATEOX kind of
routines in WIP patch.
Comments/feedbacks/doubts are welcome.
Thanks and Regards,
Kumar Rajeev Rastogi