Re:GoodJob – a Postgres-based ActiveJob back end for Ruby on...
by sideofbacon on Thursday July 23, 2020 @08:33PM
(#23934365)
GoodJob author here. I'm curious why you're specifically looking for listen/notify? I'm trying to prioritize that in the backlog.
[ Parent
| on HN ]
Re:GoodJob – a Postgres-based ActiveJob back end for Ruby on...
by juandazapata on Friday July 24, 2020 @07:16AM
(#23938102)
Hi, sorry to hijack this thread, but since you mentioned you're the author, I just wanted to ask you something. Do you have any plans to use a different locking mechanism other than the advisory lock? I'm asking because eventually every postgres-backed app that reaches a certain scale, requires a connection pooler (pgbouncer being the de-facto standard nowadays). We usually run pgbouncer in transaction mode, which doesn't support advisory locks. Any thoughts?
Re:GoodJob – a Postgres-based ActiveJob back end for Ruby on...
by sideofbacon on Friday July 24, 2020 @12:26PM
(#23941373)
That was mentioned in another thread. I have two thoughts about it:
- Going off of my own experience, I've never used PgBouncer and I've worked on some moderately sized applications (1s of millions of users). So I could say "not in scope for the target use-case".
- It would be possible to add an argument option to use a transaction-based Advisory Lock instead. I can imagine that would have downsides (long-running transactions, yikes).
I'm imagining that the lifecycle of GoodJob is that people starting new projects might choose it, and then the feature set would grow with their needs.