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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Shared row locking
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Shared row locking