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().
A1 should never be visible to Y(), else we will end up with inconsistencies. E.g.
A1 is a primary key and B1 writes a foreign key referencing A1. Commit ATX, will not complain as it sees A1, but in case X rolls back, we may have B1 referencing nothing.
Am I missing something?
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
