Re: foreign key locks, 2nd attempt

From: Jeroen Vermeulen <jtv(at)xs4all(dot)nl>
To: David Kerr <dmk(at)mr-paradox(dot)net>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: foreign key locks, 2nd attempt
Date: 2011-11-12 04:21:10
Message-ID: 4EBDF436.7000004@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2011-11-12 00:30, David Kerr wrote:

> Is this being suggested in lieu of Alvaro's patch? because it seems to be adding
> complexity to the system (multiple types of primary key definitions) instead of
> just fixing an obvious problem (over-aggressive locking done on FK checks).

It wouldn't be a new type of primary key definition, just a new type of
column constraint similar to "not null." Particularly useful with keys,
but entirely orthogonal to them.

Parser and reserved words aside, it seems a relatively simple change.
Of course that's not necessarily the same as "small."

> If it's going to be in addition to, then it sounds like it'd be really nice.

I wasn't thinking that far ahead, myself. But if some existing lock
type covers the situation well enough, then that could be a big argument
for doing it in-lieu-of.

I haven't looked at lock types much so I could be wrong, but my
impression is that there are dangerously many lock types already. One
would expect the risk of subtle locking bugs to grow as the square of
the number of interacting lock types.

Jeroen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-11-12 04:34:35 Re: fix for psql's \dd version check
Previous Message Stephen Frost 2011-11-12 01:34:40 Re: Allow substitute allocators for PGresult.