Re: NO WAIT ...

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: NO WAIT ...
Дата
Msg-id 24827.1077129458@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: NO WAIT ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: NO WAIT ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I imagine folks would want it on UPDATE, DELETE, and VACUUM FULL too,

Why?  You can do a SELECT FOR UPDATE first and then you know that you
have the row lock.  There's no need for any special handling of UPDATE
or DELETE.  I don't see the applicability to VACUUM, either.

BTW, one idea I was thinking about was that a SELECT FOR UPDATE NOWAIT
behavior might simply not return the rows it couldn't acquire lock on,
instead of erroring out.  Not sure if this would be more or less useful
than the error behavior, but I can definitely think of possible
applications for it.

> Also, I don't see this changing sematics like the regex flavor did.

You're kidding.  This is a much more fundamental change of behavior than
whether some seldom-used regex features work.  In particular, we know
that the regex behavior does not affect any other part of the system.
I do not think any equivalent safety claims can be made for random
hacking of whether LockAcquire succeeds or not.

            regards, tom lane

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

Предыдущее
От: Hans-Jürgen Schönig
Дата:
Сообщение: Re: NO WAIT ...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: NO WAIT ...