Christophe <xof@thebuild.com> writes:
> On Apr 21, 2009, at 2:15 PM, Jeff Davis wrote:
>> In Session1, the serializable transaction sees an empty version of
>> bar, even though it had tuples in at the time Session1 got its serializable
>> snapshot.
> Indeed so, and I understand that part. But since Session1 didn't try
> to access 'bar', it can't distinguish that sequence from:
Well, it could if the application has expectations about consistency
between the contents of 'foo' and 'bar'. I think we have enough
interlocks to ensure that it's not possible for an explicit foreign-key
constraint to be violated that way, but the application could have
expectations that it's not formalized as an FK. In general the point
of a serializable snapshot is to ensure that you see logically
simultaneous contents of all the tables you look at, and that will
definitely not be the case in this type of scenario.
regards, tom lane
