Robert Haas wrote:
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.
As you say, the devil is in the details, but I see this as mainly being an
implementation issue, where an essentially same task could abstract different
possible implementations, some more light or heavyweight.
This is loosely how I look at the issue conceptually, meaning like the illusion
that the DBMS presents to the user:
The DBMS is a multi-process virtual machine, the database being worked on is the
file system or disk, and uncommitted transactions are data structures in memory
that may have multiple versions. Each autonomous transaction is associated with
a single process. A process can either be started by the user (client
connection) or by another process (autonomous transaction). Regardless of how a
process is started, the way to manage multiple autonomous tasks is that each has
its own process. Tasks that are not mutually autonomous would be within the
same process. Child transactions or savepoints have the same process as their
parent when the parent can rollback their commits.
Whether the DBMS uses multiple OS threads or multiple OS processes or uses
coroutines or whatever is an implementation detail.
A point here being that over time Postgres can evolve to use either multiple OS
processes or multiple threads or a coroutine system within a single
thread/process, to provide the illusion of each autonomous transaction being an
independent process, and the data structures and algorithms for managing
autonomous transactions can be similar to or the same as multiple client
connections, since conceptually they are alike.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
