Re: Need LIMIT and ORDER BY for UPDATE

John D. Burger wrote:
> D. Dante Lorenso wrote:
>
>> I'd really like to have ORDER BY and LIMIT for UPDATE and DELETE
>> commands. Is this possible?
>>
>> UPDATE invoice i
>> SET reserve_ts = NOW() + '1 hour'::timestamp
>> FROM account a
>> WHERE a.acct_id = i.acct_id
>> AND i.reserve_ts < NOW()
>> AND a.status = 'A'
>> AND i.is_paid IS FALSE
>> ORDER BY i.create_ts ASC
>> LIMIT 1
>> RETURNING invoice_id;
>>
>> This query would find JUST ONE invoice record which is not paid and
>> reserve the right to operate on the row using the 'reserve_ts' column
>> for all active accounts. The one row would be the oldest invoice
>> matching the criteria. Only that one row would be updated and the
>> invoice_id of the updated row (if any) would be returned.
>
>> Can something like what I want be added in a future version? Ideas or
>> alternatives? I don't see how I can rewrite this query as a single
>> statement any other way and get the same expectations.
>
> Doesn't this do it, assuming invoice_id is unique?
>
> UPDATE invoice
> SET reserve_ts = NOW() + '1 hour'::timestamp
> where invoice_id =
> (select invoice_id from invoice i,
> account a
> WHERE a.acct_id = i.acct_id
> AND i.reserve_ts < NOW()
> AND a.status = 'A'
> AND i.is_paid IS FALSE
> ORDER BY i.create_ts ASC
> LIMIT 1)
> RETURNING invoice_id;

Doesn't this create race condition in the query where multiple processes
might find the same invoice_id while executing the inner select. The
update would then update the same record more than once during the
update step and 2 processes might get the same invoice_id returned. In
otherwords, moving the select criteria into a sub-query breaks the
atomic nature of the update. Right?

I have been trying to doing something like this, though:

UPDATE invoice
SET reserve_ts = NOW() + '1 hour'::timestamp
WHERE reserve_ts < NOW()
AND invoice_id = (
SELECT invoice_id
FROM invoice i, account a
WHERE a.acct_id = i.acct_id
AND i.reserve_ts < NOW()
AND a.status = 'A'
AND i.is_paid IS FALSE
ORDER BY i.create_ts ASC
LIMIT 1
)
RETURNING invoice_id;

By checking the reserve_ts inside the SELECT and again inside the UPDATE
this should catch the race condition and only allow one process to
perform the update on a given match. If the other process has updated
the reserve_ts already, the reserve_ts would not pass the second check.
However, the new side-effect is that one process would receive a NULL
return result when the race condition occurs rather than just picking up
the next queue invoice_id.

Unless I can get what I really want, this will have to do, I suppose.

-- Dante