Excerpts from Robert Haas's message of mié sep 15 14:57:29 -0400 2010:
> I guess so, but the devil is in the details. I suspect that we don't
> actually want to fork a new backend for every autonomous transactions.
> That would be pretty expensive, and we already have an expensive way
> of emulating this functionality using dblink. Finding all of the bits
> that think there's only one top-level transaction per backend and
> generalizing them to support multiple top-level transactions per
> backend doesn't sound easy, though,
Yeah, and the transaction handling code is already pretty complex.
> especially since you must do it without losing performance.
Presumably we'd have fast paths for the main transaction, and
any autonomous transactions beside that one would incur in some
slowdown.
I think the complex parts are, first, figuring out what to do with
global variables that currently represent a transaction (they are
sprinkled all over the place); and second, how to represent the
autonomous transactions in shared memory without requiring the PGPROC
array to be arbitrarily resizable.
The other alternative would be to bolt the autonomous transaction
somehow in the current subtransaction stack thing and marking it in some
different way so that we can reuse the games we play with "push/pop"
there. That still leaves us with the PGPROC problem.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
