3 ms·

Bad idea to use that because if the worker crash the event is lost, don't use PG for that.

• bloody-crow 7y ago
  Wait, what do you mean here? The job is a row in a database. You can crash as much as you want, the row is not going anywhere until you explicitly mark it as "worked" and delete it. There are different performance constraints to this approach, but data integrity and robustness of it are unmatched, really.
• ecnahc515 7y ago
  This is pubsub and the data is in an ACID compliant database. The worker will just re-subscribe and poll for events on startup.
• dragonwriter 7y ago
  > Bad idea to use that because if the worker crash the event is lost The only case where this would be problematic is if the worker crashed after doing some side effect external to the queue server that rendered the job non-idempotent, but before committing an acknowledgement. But that's not really a “what you use as a queue server” issue as a “are you also using a distributed transaction system to coordinate all side effects including queue updates” issue. (If the same Postres DB is the operational DB and the queue server, you may be able to avoid distributed transactions by having all the side effects in the DB, though that creates its own issues.)