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