On 07/27/2015 02:41 PM, Joel Jacobson wrote: > However, we should also add a way for the caller to protect against an > Autonomous Transaction in a function called by the caller. Imagine if > you're the author of function X() and within X() make use of some other > function Y() which has been written by some other author, and within > your function X(), it's very important either all of your work or none > at all gets committed, then you need to make sure none of the changes > you made before calling Y() gets committed, and thus we need a way to > prevent Y() from starting and committing an Autonomous Transaction, > otherwise we would increase the risk and complexity of working with > functions and plpgsql in PostgreSQL as you would then need to be sure > none of the functions you are using within a function will start and > commit an ATX.
Ah, you're missing how commits in ATX are expected to work. Let me illustrate: X ( Data write A1 call Y( Start ATX Data write B1 Commit ATX ) Data write A2 Exception ) In this workflow, B1 would be committed and persistent. Neither A1 nor A2 would be committed, or visible to other users. Depending on what implementation we end up with, A1 might not even be visible to Y(). So that solves your use case without any need to "block" ATXs in called functions. However, it leads to some interesting cases involving self-deadlocks; see the original post on this thread. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers