[dead]
Ways to shoot yourself in the foot with Postgres
281–290 of 329 posts
Re: Ways to shoot yourself in the foot with Postgres
#282[dead]
Re: Ways to shoot yourself in the foot with Postgres
#283[dead]
Re: Ways to shoot yourself in the foot with Postgres
#284> Setting acquired_at on read guarantees that each event is handled only once. After they've been handled, you can then delete the acquired events in batches too (there are better options than Postgres for permanently storing historical event data of unbounded size). This bothers me. It's technically true, but ignores a lot of nuance/complexity around real-world event processing needs. This approach means you will ne…
Yep, a few people have mentioned this to me here and on Reddit. I didn't know about the issues with the approach I proposed, so was pleased to read the comments. Will add a correction to the post as soon as I have a sec, thanks.
Thank you! It was a great article, and definitely pointed out a few things I'm doing wrong in my Postgres setups.
Re: Ways to shoot yourself in the foot with Postgres
#285> With that in place you could acquire events from the queue like so: UPDATE event_queue SET acquired_at = now() WHERE id IN ( SELECT id FROM event_queue WHERE acquired_at IS NULL ORDER BY occurred_at LIMIT 1000 -- Set this limit according to your usage ) RETURNING *; Would you need a FOR UPDATE in that subquery?
No, because they're setting acquired_at which marks it as "handled". You only need FOR UPDATE (SKIP LOCKED) if you want to process the event inside a transaction; but the approach in the article is to just bulk "grab the events and mark them as done, atomically"
Re: Ways to shoot yourself in the foot with Postgres
#286[dead]
Re: Ways to shoot yourself in the foot with Postgres
#287[dead]
Re: Ways to shoot yourself in the foot with Postgres
#288[dead]
Re: Ways to shoot yourself in the foot with Postgres
#289[dead]
Re: Ways to shoot yourself in the foot with Postgres
#290[dead]