Summary
I would like to ask whether queue_classic could support a configuration option to disable PostgreSQL LISTEN/NOTIFY and allow workers to run in a polling-only mode.
The main use case is running queue_classic behind PgBouncer with transaction pooling.
Background
queue_classic uses PostgreSQL as the source for jobs. Workers acquire jobs from the queue table, while LISTEN/NOTIFY is used as a wake-up mechanism when new jobs are inserted.
This works well with a direct PostgreSQL connection or with PgBouncer session pooling. However, in PgBouncer transaction pooling mode, session-level PostgreSQL features such as LISTEN/NOTIFY are not a good fit, because the backend connection is not guaranteed to remain attached to the same client session across transactions.
For this type of deployment, it would be useful to allow workers to skip LISTEN/NOTIFY and rely only on periodic polling.
Use case
In a production deployment, queue_classic workers may connect to PostgreSQL through PgBouncer.
Different connection modes have different requirements:
- Direct PostgreSQL connection:
LISTEN/NOTIFY is appropriate.
- PgBouncer session pooling:
LISTEN/NOTIFY can still be usable.
- PgBouncer transaction pooling: polling-only behavior may be preferable.
Without a way to disable LISTEN/NOTIFY, it is harder to use queue_classic in transaction pooling environments.
Desired behavior
I am not proposing to change the default behavior.
I would like to propose an opt-in configuration option that allows users to disable LISTEN/NOTIFY.
For example, this could be exposed through an environment variable or configuration setting, such as:
or a similarly named option.
When enabled or unset, queue_classic would keep the current behavior.
When disabled, workers would avoid using LISTEN/NOTIFY and rely on the configured polling interval to check for available jobs.
Why this would be useful
This would make queue_classic easier to deploy with PgBouncer transaction pooling, while preserving the current behavior for existing users.
It would also make the worker behavior more explicit for deployments where connection pooling strategy matters.
Questions
Would the maintainers be open to supporting a polling-only worker mode?
If so, would an environment variable, a Ruby configuration option, or both be the preferred interface?
Summary
I would like to ask whether queue_classic could support a configuration option to disable PostgreSQL
LISTEN/NOTIFYand allow workers to run in a polling-only mode.The main use case is running queue_classic behind PgBouncer with transaction pooling.
Background
queue_classic uses PostgreSQL as the source for jobs. Workers acquire jobs from the queue table, while
LISTEN/NOTIFYis used as a wake-up mechanism when new jobs are inserted.This works well with a direct PostgreSQL connection or with PgBouncer session pooling. However, in PgBouncer transaction pooling mode, session-level PostgreSQL features such as
LISTEN/NOTIFYare not a good fit, because the backend connection is not guaranteed to remain attached to the same client session across transactions.For this type of deployment, it would be useful to allow workers to skip
LISTEN/NOTIFYand rely only on periodic polling.Use case
In a production deployment, queue_classic workers may connect to PostgreSQL through PgBouncer.
Different connection modes have different requirements:
LISTEN/NOTIFYis appropriate.LISTEN/NOTIFYcan still be usable.Without a way to disable
LISTEN/NOTIFY, it is harder to use queue_classic in transaction pooling environments.Desired behavior
I am not proposing to change the default behavior.
I would like to propose an opt-in configuration option that allows users to disable
LISTEN/NOTIFY.For example, this could be exposed through an environment variable or configuration setting, such as:
or a similarly named option.
When enabled or unset, queue_classic would keep the current behavior.
When disabled, workers would avoid using
LISTEN/NOTIFYand rely on the configured polling interval to check for available jobs.Why this would be useful
This would make queue_classic easier to deploy with PgBouncer transaction pooling, while preserving the current behavior for existing users.
It would also make the worker behavior more explicit for deployments where connection pooling strategy matters.
Questions
Would the maintainers be open to supporting a polling-only worker mode?
If so, would an environment variable, a Ruby configuration option, or both be the preferred interface?