Re: SELECT FOR UPDATE and LIMIT 1 behave oddly

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SELECT FOR UPDATE and LIMIT 1 behave oddly
Дата
Msg-id 5385.1097818216@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SELECT FOR UPDATE and LIMIT 1 behave oddly  (Neil Conway <neilc@samurai.com>)
Ответы Re: SELECT FOR UPDATE and LIMIT 1 behave oddly  (Neil Conway <neilc@samurai.com>)
Список pgsql-bugs
Neil Conway <neilc@samurai.com> writes:
> On Fri, 2004-10-15 at 14:22, Tom Lane wrote:
>> What if some of the locked rows didn't get returned to the client?

> In the case of SELECT ... FOR UPDATE LIMIT x, exactly the same condition
> applies: some number of locked rows will not be returned to the client.

Au contraire: every row that gets locked will be returned to the client.
The gripe at hand is that the number of such rows may be smaller than
the client wished, because the LIMIT step is applied before we do the
FOR UPDATE step (which has not only the effect of locking selected rows,
but of disregarding rows that were deleted since our query snapshot).

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: SELECT FOR UPDATE and LIMIT 1 behave oddly
Следующее
От: Neil Conway
Дата:
Сообщение: Re: SELECT FOR UPDATE and LIMIT 1 behave oddly