Re: Feature: FOR UPDATE SKIP LOCKED
От | Craig Ringer |
---|---|
Тема | Re: Feature: FOR UPDATE SKIP LOCKED |
Дата | |
Msg-id | 4874759C.7050801@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: Feature: FOR UPDATE SKIP LOCKED (Csaba Nagy <nagy@ecircle-ag.com>) |
Ответы |
Re: Feature: FOR UPDATE SKIP LOCKED
|
Список | pgsql-general |
Csaba Nagy wrote: > On Wed, 2008-07-09 at 00:48 -0400, Tom Lane wrote: >> "Jonathan Bond-Caron" <jbondc@gmail.com> writes: >>> It would be quite useful to implement a database queue. Although FOR UPDATE >>> NOWAIT and trying again can work as well as other techniques, >>> just skipping over the locks has its advantages (simplicity and zero wait) >> And disadvantages, such as complete lack of predictability or failure >> detection. > > Well, it's not like SQL is completely predictable in general... think > about ordering of results. Such a feature would definitely help queue > like table processing, and the fact that it is predictably unpredictable > should not be a surprise for anybody using such a feature... Especially if it returned an updated row count or supported the RETURNING clause, so you could find out after the fact what was or wasn't done. -- Craig Ringer
В списке pgsql-general по дате отправления: