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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
