On Wed, 2008-01-23 at 00:26 -0800, Neil Conway wrote:
> On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
> > And there is most important question about data visibility - is
> > autonomous transaction independent on main transaction (isolation)?
>
> >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.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On Wed, 2008-01-23 at 09:30 +0000, Gregory Stark wrote:
> I think the hard part would be error handling. You have to be able to catch
> any errors and resume the outer transaction.

I agree that you'd need to do this, but I don't follow why it would be
particularly difficult. You essentially have a stack of active
transactions (since one autonomous transaction can start another
autonomous transaction, and so forth). If you encounter an error in the
current transaction, you abort it as normal, pop the stack, and resume
execution of the originating transaction.

I think the hard part is fixing the parts of the backend that assume
that a single process can only have a single top-level transaction in
progress at a given time.

-Neil



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Simon Riggs <simon@2ndquadrant.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 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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Jan 24, 2008 2:46 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote:

> Gokulakannan Somasundaram escribió:
>
> > The Audit transaction, which is a autonomous transaction need not catch
> any
> > error and resume the outer transaction.
>
> What if the logging fails, say because you forgot to create the audit
> table?
>
I get it now...

>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

On Jan 23, 2008 10:06 PM, Gokulakannan Somasundaram <gokul007@gmail.com> wrote:
> On Jan 24, 2008 2:46 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> > > The Audit transaction, which is a autonomous transaction need not catch
> any
> > > error and resume the outer transaction.
> >
> > What if the logging fails, say because you forgot to create the audit
> > table?
> >
> I get it now...

Autonomous transactions are, umm, autonomous. The calling transaction
doesn't know about or care whether the autonomous transaction succeeds
or fails for any reason.

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq