-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forward parameters to compute in proxy #1287
Comments
The proxy should pass through everything, and let Postgres reject invalid ones. It's not the proxy's job to guess which ones are valid, IMHO. If necessary, the proxy could recognize some options to control the proxy itself, though. I don't know if we have any such options today, or if that's needed in the future. |
Plus one on passthrough except authentication parameters that proxy changes because it performs the mapping via console. Also such parameters as encryption settings for connection from proxy to compute are controlled by us and user cannot affect them. |
I'm going to tackle this. |
Are there any paramenters that are critical to pass through for the nearest milestones? |
Previously, proxy didn't forward auxiliary `options` parameter and other ones to the client's compute node, e.g. ``` $ psql "user=john host=localhost dbname=postgres options='-cgeqo=off'" postgres=# show geqo; ┌──────┐ │ geqo │ ├──────┤ │ on │ └──────┘ (1 row) ``` With this patch we now forward `options`, `application_name` and `replication`. Further reading: https://www.postgresql.org/docs/current/libpq-connect.html Fixes #1287.
I tested this on staging with this little test program (from https://community.neon.tech/t/error-connecting-edgedb-intervalstyle-parameter-ignored/107/6):
It prints:
But against a local postgres installation, it prints:
The latter is expected. It seems to me that the IntervalStyle option is still not passed through. |
Huh... I guess it's time to bite the bullet and lift the limitations imposed by tokio-postgres. |
TODO: tokio-postgres Config needs to accept an arbitrary "options" parameter that we can feed in our options into. The |
## Problem Fixes #1287 ## Summary of changes tokio-postgres now supports arbitrary server params through the `param(key, value)` method. Some keys are special so we explicitly filter them out.
Currently proxy eats parameters that are not needed for it e.g it doesn't pass application name to compute.
The other question is what is a precise list of parameters we need to support? Are there any parameters that we fundamentally cannot support?
The text was updated successfully, but these errors were encountered: