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:40:42 |
Message-ID: | 55B6C17A.5090108@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
[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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-07-27 23:43:47 | Re: Autonomous Transaction is back |
Previous Message | David Rowley | 2015-07-27 23:22:45 | Re: Optimization idea: merging multiple EXISTS(...) with constraint-based join removal |