4 ms·
Not sure. Maybe something else is responsible for identifying "stuck" jobs and kicking them out to humans to decide what to do (assuming worker crashes are rare
by jffry 5y ago
Not sure. Maybe something else is responsible for identifying "stuck" jobs and kicking them out to humans to decide what to do (assuming worker crashes are rare)
If we're talking PostgreSQL specifically, and newer-ish Postgres (9.5+ I think), then you can leverage its abilities to do all this in one atomic query:
UPDATE jobs
SET status='working'
WHERE id = (SELECT id
FROM jobs
WHERE status=NULL
LIMIT 1
FOR UPDATE
SKIP LOCKED)
RETURNING id
- shawnz 5y agoIf you are willing to use SELECT ... FOR UPDATE SKIP LOCKED, then you can implement the queue without any UPDATE query or status column at all. Just lock the record to mark it as in progress, that is how you get the benefit that when the worker crashes, it will automatically be returned to the queue.