| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> | 
|---|---|
| To: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: Feature: FOR UPDATE SKIP LOCKED | 
| Date: | 2008-07-09 08:23:56 | 
| Message-ID: | 4874759C.7050801@postnewspapers.com.au | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
Csaba Nagy wrote:
> On Wed, 2008-07-09 at 00:48 -0400, Tom Lane wrote:
>> "Jonathan Bond-Caron" <jbondc(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2008-07-09 08:24:21 | Re: Getting source code for database objects | 
| Previous Message | Richard Huxton | 2008-07-09 08:21:28 | Re: plpgsql - or operator? |