Hacker News Reader

My understanding is that a naive implementation essentially serializes access to the queue table. So it works, but no matter how many requests you make in parallel, only one will be served at a time (unless you have a random component in the query).

With SKIP LOCKED you can resolve this easily, as long as you know about the feature. But almost every tutorial and description of implementing a job queue in Postgres mentions this now.

You can do an a select statement skipping locked rows in postgres.

Specifically you also want SELECT ... FOR UPDATE SKIP LOCKED;

I believe that problem is avoided by using SKIP LOCKED[0].

[0] https://www.2ndquadrant.com/en/blog/what-is-select-skip-lock...