| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2007-02-02 10:26:49 | Re: A more general approach (Re: Data archiving/warehousing idea) |
| Previous Message | Csaba Nagy | 2007-02-02 10:14:15 | Re: Referential Integrity and SHARE locks |