On Tue, Apr 8, 2014 at 2:43 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Greg Stark wrote:
>> If the autonomous transaction is actually a separate procarray entry
>> (which I suspect it would have to be, much like prepared transactions
>> and the dblink connections which are commonly used to kludge
>> autonomous transactions) then this should be fairly painless. If you
>> implement some kind of saving and restoring procarray data then it
>> probably wouldn't work out.
>
> I don't have time to digest this proposal ATM, but in previous occasion
> when we have discussed autonomous transactions (ATs), we have always
> considered natural that they have their own procarray entries; there are
> too many strange issues otherwise.
>
> Since the number of procarray entries is fixed at startup time, one
> natural consequence of this is that the number of ATs in flight at any
> moment is also fixed. Normally we consider allocating a single AT per
> session to be sufficient. So you can't have one AT start another AT,
> for instance -- that seems a reasonable restriction.
It depends. A lot of Oracle users are used to having autonomous
transactions be very cheap, so you can just mark random procedures as
running in an autonomous transaction and forget about it. If the call
stack is several levels deep, then you could easily have one such
procedure call another such procedure. Of course, you may feel that's
bad practice or that we shouldn't emulate what $COMPETITOR does, and I
agree we don't have to necessarily do it that way just because they do
it that way, but I'm not sure it's accurate to say that nobody will
care.
I'm also pretty unconvinced that multiple PGPROCs is the right way to
go. First, PGPROCs have a bunch of state in them that is assumed to
exist once per backend. We might find pretty substantial code churn
there if we try to go change that. Second, why do other backends
really need to know about our ATs? As far as I can see, if other
backends see the AT as a subtransaction of our top-level transaction
up until it actually commits, that ought to be just fine. Maybe the
backend needs to internally frob visibility rules, but that's not a
matter for shared memory.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
