>    It  does  a  SELECT  ...  FOR  UPDATE because we don't have a
>    SELECT ... AND PLEASE DO NOT REMOVE.
>
>    If we would only check  if  the  PK  is  there  now,  another
>    concurrent  transaction  could  delete the PK, it's own check
>    cannot see our uncommitted row yet  and  we  end  up  with  a
>    violation.  And if you look at the comment a few lines up, it
>    explains why we cannot skip the check even if the  key  value
>    doesn't change.

But it does not apply here since there are no "on update set default" here. So IMO this case should not apply if there are not "on update set default"? Or are other cases where the same restriction applies?

The problem is this, at the moment there is no such thing as "row level locking" in postgres when you use foreign key constraints. This really hits concurrency.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Thu, 28 Mar 2002 17:33:53 +0100
"Mario Weilguni" <mario.weilguni@icomedias.com>
Re: deadlock problems with foreign keys