Re: Autonomous Transaction (WIP)

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Autonomous Transaction (WIP)
Date: 2014-04-10 05:14:23
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DDE035A@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

Thanks and Regards,
Kumar Rajeev Rastogi

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-04-10 05:35:49 Re: [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0
Previous Message Tomonari Katsumata 2014-04-10 04:19:28 small typo about comment in xlog.c