Re: BUG #4648: needless deadlock on tables having foreign-key

From: Konstantin <kostya2702(at)rambler(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #4648: needless deadlock on tables having foreign-key
Date: 2009-02-13 08:30:39
Message-ID: 172745599.1234513839.206304664.53080@mcgi16.rambler.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [Thu, 12 Feb 2009 19:10:34 -0500]:
> [ shrug... ] The "implementation artifact" is that you didn't get a
> deadlock *earlier*.

I agree that such behavior is more plain rather than current.

> You can't expect to update referenced rows and
> referencing rows in the same transaction and not risk deadlock against
> other transactions doing the same thing.

No. One transaction works with referenced rows only. Another with
referencing rows only.

I expect predictability, then flexibility (locks optimization).
So what is your recommendation?
To avoid deadlock do I need lock all referencing rows if I need to
update referenced row(s)?

Something like ` select * from bill1 where pid = 1 or aid = 1 for
update; ` in the first session of example?

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Nitin 2009-02-13 11:29:18 BUG #4651: Postgresql connection error with PHP 5.
Previous Message Scott Carey 2009-02-13 05:53:45 8.3.5: Query Planner takes 15+ seconds to plan Update or Delete queries on partitioned tables.