The comment you are replying to wasn't addressing that scenario.

Typically you would implement visibility timeouts and other such stuff. Depending on the use case you could make specific optimizations or keep it generic and have SQS like semantics or something.

at this point why not use something like rabbitmq and not reinvent it in postgres.

Because it's trivially easy. The dequeue operation updates the last_lease time; the query makes sure you don't dequeue something that was recently leased. It's far, far easier than setting up a separate job queue, especially if you are already using an RDBMS.

Because then you're running and maintaining another service. Might make sense, but depends.

You need some timeout and/or leasing mechanism to make it work in this scenario.