Re: Referential Integrity and SHARE locks
От | Csaba Nagy |
---|---|
Тема | Re: Referential Integrity and SHARE locks |
Дата | |
Msg-id | 1170414114.3101.81.camel@coppola.muc.ecircle.de обсуждение исходный текст |
Ответ на | Re: Referential Integrity and SHARE locks (Richard Huxton <dev@archonet.com>) |
Ответы |
Re: Referential Integrity and SHARE locks
Re: Referential Integrity and SHARE locks |
Список | pgsql-hackers |
> 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. For the conditions of generating the deadlock, see: http://archives.postgresql.org/pgsql-general/2006-12/msg00029.php The reason of the occasional orphan rows is not completely clear to me, but it must be some kind of race condition while inserting/deleting/?updating concurrently the parent/child tables. Cheers, Csaba.
В списке pgsql-hackers по дате отправления: