On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan <dar...@darrenduncan.net> wrote: > The point being, the answer to how to implement autonomous transactions > could be as simple as, do the same thing as how you manage multiple > concurrent client sessions, more or less. If each client gets its own > Postgres OS process, then an autonomous transaction just farms out to > another one of those which does the work. Or maybe there could be a lighter > weight version of this. > > Does this design principle seem reasonable?
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, especially since you must do it without losing performance. -- 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
