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 ATXData write B1Commit 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