Re: [HACKERS] foreign key introduces unnecessary locking ? - Mailing list pgsql-sql

From Jan Wieck
Subject Re: [HACKERS] foreign key introduces unnecessary locking ?
Date
Msg-id 200010221226.HAA00859@jupiter.jw.home
Whole thread Raw
In response to RE: [HACKERS] foreign key introduces unnecessary locking ?  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-sql
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
possibleto 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@Yahoo.com #




pgsql-sql by date:

Previous
From: jan.bajerski@viterra.pl
Date:
Subject:
Next
From: Stephan Szabo
Date:
Subject: Re: