Re: Autonomous Transaction (WIP) - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Autonomous Transaction (WIP)
Date
Msg-id CABOikdNcZ7kD2zFieYUoSY09TVHR5_cXQqrq66DaSA57_GcVrQ@mail.gmail.com
Whole thread Raw
In response to Re: Autonomous Transaction (WIP)  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
List pgsql-hackers



On Thu, Apr 10, 2014 at 10:44 AM, Rajeev rastogi <rajeev.rastogi@huawei.com> wrote:

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 etc.
 

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.

Thanks,

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0
Next
From: Pavel Stehule
Date:
Subject: Re: four minor proposals for 9.5