Re: foreign key introduces unnecessary locking ?

Mikheev, Vadim wrote:
> Try this for both FK tables:
>
> create table tmp2(idx2 int4, col2 int4, constraint
> tmpcon2 foreign key(col2) references tmp1(idx) INITIALLY DEFERRED);
>
> This will defer constraint checks till transaction commit...
> though constraint triggers should use SnapshotDirty instead of
> SELECT FOR UPDATE anyway.
>
> Did you consider this, Jan?
>
> Vadim

Whenever the checks are done, the transaction inserting a new
reference to the key must ensure that this key cannot get
deleted until it is done and it's newly inserted reference is
visible to others. Otherwise a referential action,
preventing referenced key deletion (or other action) wouldn't
see those and it would be possible to violate the constraint.

I don't see any other way doing it than obtaining a lock.
Using SnapshotDirty would mean, that one transaction could
DELETE a reference, then another transaction removes the
primary key (because using Dirty the DELETE is already
visible), but now the first transaction rolls back. Voila,
constraint violated.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #