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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>    It  does  a  SELECT  ...  FOR  UPDATE because we don't have a
>    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 address at

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-2017 The PostgreSQL Global Development Group