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
transaction properties).
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
transaction properties.
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
