> 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