GoodJob author here. I'm curious why you're specifically looking for listen/notify? I'm trying to prioritize that in the backlog.

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?

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.