On Tue, Apr 8, 2014 at 2:43 PM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
