Re: Referential Integrity and SHARE locks
От | Richard Huxton |
---|---|
Тема | Re: Referential Integrity and SHARE locks |
Дата | |
Msg-id | 45C311A1.6080106@archonet.com обсуждение исходный текст |
Ответ на | Re: Referential Integrity and SHARE locks (Csaba Nagy <nagy@ecircle-ag.com>) |
Ответы |
Re: Referential Integrity and SHARE locks
|
Список | 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
В списке pgsql-hackers по дате отправления: