On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan <darren@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
havean 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
