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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
