On Thu, Apr 10, 2014 at 10:44 AM, Rajeev rastogi
> On 09 April 2014 12:14, Pavan Deolasee Wrote:
> >Whenever I was asked to have a look at implementing this feature, I
> always wondered about the great amount of global state that a backend
> maintains which is normally tied to a single top transaction. Since AT will
> have same characteristics as a top level transaction, I
> >wonder how do you plan to separate those global state variables ? Sure,
> we can group them in a structure and put them on a stack when an AT starts
> and pop them off when the original top transaction becomes active again,
> finding all such global state variables is
> >going to be tricky.
> 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
> 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.