zlacker

[parent] [thread] 3 comments
1. osigur+(OP)[view] [source] 2023-04-27 00:01:49
>> In my previous job we used Postgres to implement a task queuing system, and it created a major bottleneck, resulting in tons of concurrency failures and bloat

Yet, every month or two an article about doing exactly this is upvoted to near the top of HN. It can of course work but might hard to replace years later once "barnacles" have grown on it. Every situation is different of course.

replies(2): >>guywho+U2 >>johnth+Y64
2. guywho+U2[view] [source] 2023-04-27 00:29:59
>>osigur+(OP)
I've built this queue system probably 5 times, first 2-3 were failures as consumer concurrency was 1 without us noticing for hours. The bloat comes from updating the work instead of deleting I assume, did for me. There are definitely many ways to not do it right but kinda works.
replies(1): >>osigur+b5
◧◩
3. osigur+b5[view] [source] [discussion] 2023-04-27 00:49:31
>>guywho+U2
Yeah, it is strange that hokey, home grown solutions built on top of Postgres are suddenly in vogue.
4. johnth+Y64[view] [source] 2023-04-28 04:07:24
>>osigur+(OP)
skip locks are the secret for queues in pg. did you use skip locks?
[go to top]