Tom Lane wrote:
This is what I am wondering. Whether it is done this way due to
expecation/standard, or as an implementation side effect. In the
latter case it is fixable.
I don't see how this could break a standard.
Actually, I think it does, because we went to great lengths to cause
Peter Schuller wrote:
[about a serialization error caused by a foreign key constraint]
Transaction 2 now issues an INSERT on atable. This requires a
RowShareLock on the index row of the index on othertable that
is referenced by the foreign key constraint. But the corresponding
index row has
Albe Laurenz [EMAIL PROTECTED] writes:
Peter Schuller wrote:
This is what I am wondering. Whether it is done this way due to
expecation/standard, or as an implementation side effect. In the
latter case it is fixable.
I don't see how this could break a standard.
Actually, I think it does,
