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

Reply via email to