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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
