Re: SELECT FOR UPDATE differs inside and outside a pl/pgsql

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SELECT FOR UPDATE differs inside and outside a pl/pgsql
Дата
Msg-id 19667.1071760293@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SELECT FOR UPDATE differs inside and outside a pl/pgsql  (Mark Shewmaker <mark@primefactor.com>)
Список pgsql-bugs
Mark Shewmaker <mark@primefactor.com> writes:
> On Wed, 2003-12-17 at 19:57, Tom Lane wrote:
>> Mark Shewmaker <mark@primefactor.com> writes:
>>> If a "FOR UPDATE executes before LIMIT" rule stopped the function
>>> from ever locking a row, it's still curious why didn't it stop the
>>> direct command from ever locking a row as well.
>>
>> I think it would.  Did you try the test the other way around (with the
>> direct command being blocked behind someone who deletes the first row)?

> Yes, or at least I've done the test that I think you're asking about.

So you have.  Your session B_1 (second column) shows exactly the
behavior I expected: the first invocation of SELECT FOR UPDATE
fails to lock any row.  You manually did the equivalent of looping
as in myfunction().  So it looks the same to me.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #1013: Authentication doesn't work
Следующее
От: Rich Hall
Дата:
Сообщение: Re: plpgsql For SQLQuery Loop Flags Error