 <p>This approach will work with PostgreSQL but it'll tend to be pretty inefficient as you're updating each row twice - each update requires <em>two</em> transactions, two commits. The cost of this can be mitigated somewhat by using a <code>commit_delay</code> and possibly disabling <code>synchronous_commit</code>, but it's still not going to be fast unless you have a non-volatile write-back cache on your storage subsystem.</p> <p>More importantly, because you're committing the first update there is no way to tell the difference between a worker that's still working on the job and a worker that has crashed. You could probably set the token to the worker's process ID if all workers are on the local machine then scan for missing PIDs occasionally but that's cumbersome and race-condition prone, not to mention the problems with pid re-use.</p> <p>I would recommend that you adopt a <em>real</em> queuing solution that is designed to solve these problems, like ActiveMQ, RabbitMQ, ZeroMQ, etc. <a href="http://wiki.postgresql.org/wiki/PGQ_Tutorial" rel="nofollow">PGQ</a> may also be of significant interest.</p> <p>Doing queue processing in a transactional relational database <em>should</em> be easy, but in practice it's ridiculously hard to do well and get right. Most of the "solutions" that look sensible at a glance turn out to actually serialize all work (so only one of many queue workers is doing anything at any given time) when examined in detail. </p>