Re: foreign key locks, 2nd attempt - Mailing list pgsql-hackers

From Jeroen Vermeulen
Subject Re: foreign key locks, 2nd attempt
Date
Msg-id 4EBDF436.7000004@xs4all.nl
Whole thread Raw
In response to Re: foreign key locks, 2nd attempt  (David Kerr <dmk@mr-paradox.net>)
List 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


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Allow substitute allocators for PGresult.
Next
From: Robert Haas
Date:
Subject: Re: fix for psql's \dd version check