On Wed, Sep 15, 2010 at 6:21 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > 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.
Yep. >> 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. I wonder if we could use/generalize pg_subtrans in some way to handle the PGPROC problem. I haven't thought about it much, though. One thing that strikes me (maybe this is obvious) is that the execution of the main transaction and the autonomous transaction are not interleaved: it's a stack. So in terms of globals and stuff, assuming you knew which things needed to be updated, you could push all that stuff off to the side, do whatever with the new transaction, and then restore all the context afterwards. That doesn't help in terms of PGPROC, of course, but for backend-local state it seems workable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
