Skip site navigation (1) Skip section navigation (2)

Re: deadlock problems with foreign keys

From: "Mario Weilguni" <mario(dot)weilguni(at)icomedias(dot)com>
To: "Postgresql Mailinglist (E-Mail)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: deadlock problems with foreign keys
Date: 2002-03-28 16:33:53
Message-ID: D143FBF049570C4BB99D962DC25FC2D2178092@freedom.icomedias.com (view raw or flat)
Thread:
Lists: pgsql-hackers
>    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


pgsql-hackers by date

Next:From: Rod TaylorDate: 2002-03-28 16:57:14
Subject: Alter function?
Previous:From: Stephan SzaboDate: 2002-03-28 16:30:53
Subject: Re: deadlock problems with foreign keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group