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

Re: Referential Integrity and SHARE locks

From: Richard Huxton <dev(at)archonet(dot)com>
To: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>,postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Referential Integrity and SHARE locks
Date: 2007-02-02 10:25:37
Message-ID: 45C311A1.6080106@archonet.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Csaba Nagy wrote:
> On Fri, 2007-02-02 at 10:51, Simon Riggs wrote:
> [snip]
>> Why do we need a SHARE lock at all, on the **referenc(ed)** table?

> Well, here we do have a patch (deployed on production servers) which
> does not put the shared lock on the referenced table, and it lets in
> occasionally rows in the referencing tables which do not have parent
> rows in the referenced table. I'm not sure what is the mechanism, but it
> does happen, I can assure you. It happens rare enough that is not
> disturbing for us, compared to the deadlocks which happen without the
> patch - that's another matter...

You say below the cut that you're not updating keys, so presumably it's 
other columns. Which leads me to something I've wondered for a while - 
why do we lock the whole row? Is it just a matter of "not optimised that 
yet" or is there a good reason why locking just some columns isn't 
practical.

-- 
   Richard Huxton
   Archonet Ltd

In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2007-02-02 10:26:49
Subject: Re: A more general approach (Re: Dataarchiving/warehousing idea)
Previous:From: Csaba NagyDate: 2007-02-02 10:14:15
Subject: Re: Referential Integrity and SHARE locks

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