On Jan 25, 2008, at 7:27 AM, Decibel! wrote:
On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote:
From looking at how Oracle does them, autonomous transactions are
completely independent of the transaction that originates them -- they
take a new database snapshot. This means that uncommitted changes in the
originating transaction are not visible to the autonomous transaction.
Oh! Recursion depth would need to be tested for as well. Nasty.
Seems like the cloning-a-session idea would be a possible implementation
path for these too.
Oracle has a feature where you can effectively save a session and return
to it. For example, if filling out a multi-page web form, you could save
state in the database between those calls. I'm assuming that they use
that capability for their autonomous transactions; save the current
session to the stack, clone it, run the autonomous transaction, then
restore the saved one.
If you want to use it for webforms you cannot just put it on the stack - you had to put it in shared memory because you don't know if you will ever get the same database connection back from the pool.
personally i like marko's idea. if a snapshot was identified by a key it would be perfect. we could present the snapshots saved as a nice nice superuser-readable system view (similar to what we do for 2PC)
the only thing i would do is to give those snapshots some sort of timeout (configurable). otherwise we will get countless VACUUM related reports.
this sounds like a very cool feature - definitely useful.
many thanks,
hans
--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340