On Mon, Nov 28, 2022 at 12:11:53PM -0500, Tom Lane wrote:
> So basically it's unsafe to run the sub-select more than once,
> but the query as written leaves it up to the planner whether
> to do that. I'd suggest rephrasing as
>
> WITH target_rows AS MATERIALIZED (
> SELECT id
> FROM queue
> ORDER BY id
> LIMIT 1
> FOR UPDATE
> SKIP LOCKED
> )
> DELETE FROM queue
> WHERE id IN (SELECT * FROM target_rows)
> RETURNING *;
Thanks for the explanation and suggested fix, Tom.
I'm not the original poster, but I do use similar constructions for simple
postgres queues. I've been trying for a while, but I don't understand where the
extra rows come from, or what's "silent" about SKIP LOCKED.
Because we get different results depending on the plan postgres picks, I can
see two options: either the query is broken, or postgres is broken. Assuming it's
the former, would there be a way to make it clearer that the "obvious" (to me)
way to use SKIP LOCKED is wrong?
Thanks!
Harmen
