Re: Autonomous Transaction is back

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Joel Jacobson <joel(at)trustly(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Autonomous Transaction is back
Date: 2015-07-27 23:47:02
Message-ID: 55B6C2F6.20907@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/27/15 6:40 PM, Jim Nasby wrote:
> On 7/27/15 5:12 PM, Joel Jacobson wrote:
>> Right now, when writing a function, if you raise an exception, you can
>> be sure all writes you have made will be rollbacked, but your caller
>> function might caught the exception and decide to carry on and commit
>> work made before your function was called, but at least you can be
>> confident your writes won't be committed as long as you don't caught the
>> exception you raised in your own function. If I understand it correctly,
>> that would change with the addition of Autonomous Transaction, unless
>> given a way to prevent a function you call from starting and commiting
>> a Autonomous Transaction. Wrong? If so, then please show how to prevent
>> Y() from commiting the "Data write B1" in your example, I don't get it.
>
> What's being described here doesn't make sense in either use case ([1] &
> [2]), but I do understand the concern about what 3rd party software is
> doing. It would be nice to have the ability to disallow and/or disable
> autonomous transactions, but I don't see a practical way of doing that
> other than introducing a new GUC. I'm not sure if it's worth that effort.

It just occurred to me that another option would be to have an event
trigger for beginning an autonomous transaction.

> [1] the "batch process" use case: batches that still hold their own
> transaction open don't gain anything.
>
> [2] the "audit logging" case. If you didn't care about auditing
> surviving regardless of a rollback then you wouldn't go to the extra
> work of an autonomous transaction to begin with.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-07-27 23:57:55 Re: Several memory leaks for pg_rewind caused by missing PQclear calls
Previous Message Jim Nasby 2015-07-27 23:43:47 Re: Autonomous Transaction is back