On 07/27/2015 03:12 PM, Joel Jacobson wrote:
> On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus <josh@agliodbs.com
> <mailto:josh@agliodbs.com>> wrote:
>
> 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.
>
>
> I don't follow. In your example above, if I'm X(), how do I ensure Y()
> won't have committed anyting at all when I later at "Exception" decide
> to rollback everything from "Data write A1" to "Data write A2" including
> any writes made by Y() (in the example "Data write B1")?
Ah, ok. The goal of the project is that the writer of X() *cannot*
prevent Y() from writing its data (B1) and committing it.
One of the primary use cases for ATX is audit triggers. If a function
writer could override ATX and prevent the audit triggers from
committing, then that use case would be violated.
Can you explain what use case you have where simply telling the staff
"if you use ATX without clearing it, you'll be fired" is not sufficient?Possibly there's something we failed to account
forin the unconference
discussion.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
