Re: Shared row locking
От | Tom Lane |
---|---|
Тема | Re: Shared row locking |
Дата | |
Msg-id | 16664.1103491366@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Shared row locking (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Shared row locking
Re: Shared row locking |
Список | pgsql-hackers |
Heikki Linnakangas <hlinnaka@iki.fi> writes: > On Sun, 19 Dec 2004, Alvaro Herrera wrote: >> This is not useful at all, because the objective of this exercise is to >> downgrade locks, from exclusive row locking (SELECT ... FOR UPDATE) to >> shared row locking. > Actually it might help in some scenarios. Remember, we're not talking > about upgrading shared locks to exclusive locks. We're only talking about > locking more rows than necessary (all rows). Nonetheless, it would mean that locks would be taken depending on implementation-dependent, not-visible-to-the-user considerations. Shared locks can still cause deadlocks, and so you would have an unreliable application, which would only be unreliable under load. As I said in connection with the other proposal, weird user-visible semantics should be the last resort not the first. regards, tom lane
В списке pgsql-hackers по дате отправления: