On Jan 25, 2008, at 7:27 AM, Decibel! wrote:
> On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote:
>> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>>>> 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
>>> Oh! Recursion depth would need to be tested for as well. Nasty.
>> Seems like the cloning-a-session idea would be a possible
>> path for these too.
> Oracle has a feature where you can effectively save a session and
> to it. For example, if filling out a multi-page web form, you could
> 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
this sounds like a very cool feature - definitely useful.
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
In response to
pgsql-hackers by date
|Next:||From: Marko Kreen||Date: 2008-01-29 08:06:45|
|Subject: Re: [GENERAL] SHA1 on postgres 8.3|
|Previous:||From: Kris Jurka||Date: 2008-01-29 05:09:28|
|Subject: Re: Proposed patch: synchronized_scanning GUC variable|