Listen for postgres events using owner connection url
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 625
- Avg merge
- 5h 23m
- Merged PRs (30d)
- 24
Description
### Feature description
I'd like the pg client that's handling the notification subscription to use the owner connection string instead of the client connection string.
### Motivating example
In my environment I use pgbouncer in transaction pool mode by default. This unfortunately silently eats all notifications coming from postgres as there's not a session to send them back to. I do separate my postgres client connection string from the owner connection string to limit superuser exposure. This enables me to still keep the more optimal transaction pooling of pgbouncer for routine client queries/mutations. The present workaround is to either use session pooling in pgbouncer or drop it entirely unfortunately.
### Breaking changes
For users who don't separate the owner connection string, there's no difference. For users that do, it might change behavioral expectations on that owner client connection to be short lived.
### Supporting development
I [tick all that apply]:
- [ ] am interested in building this feature myself
- [ ] am interested in collaborating on building this feature
- [ ] am willing to help testing this feature before it's released
- [ ] am willing to write a test-driven test suite for this feature (before it exists)
- [ ] am a [Graphile sponsor](https://www.graphile.org/sponsor/) ❤️
- [ ] have an active [support or consultancy contract](https://www.graphile.org/support/) with Graphile
Contributor guide
Research direction
Start by locating the PostgreSQL notification subscription code and the configuration that distinguishes the client and owner connection URLs. Reproduce the separate-URL setup with PgBouncer in transaction-pooling mode, then verify that notifications are received through the owner connection without changing behavior when the URLs are the same.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- postgresql, typescript
- Domain
- backend, database
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100