-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
fix(server): filter parameters by database and role #19392
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
Conversation
Sorry for interfering... while your at this function, wouldn´t
do the trick ? |
Unfortunately not. Postgres 15 and later doesn't allow setting or resetting a parameter with a reserved prefix unless that parameter is recognized by an extension. Since the extension no longer uses this parameter, Postgres doesn't let us unset it either. This is a roundabout way to reset it as a result. |
will fix #19391 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const { db, guc } = res.rows[0]; |
How confident can we be that this always returns only one row?
I guess if we are scoping for (current DB) AND (global roles) they SHOULD all be contained in one row, but I am not 100% sure of this.
EDIT: I think there is only one row per DB+role combo: https://www.postgresql.org/docs/current/catalog-pg-db-role-setting.html
Should
|
If the Postgres instance has multiple database besides immich and one of them has a database or role wide parameter override set, it is possible for the migration to apply the wrong parameters. Immich happens to work without the right parameters set unless Postgres is also using pgvecto.rs, and it's unlikely for the incorrect parameters to be disruptive. But it's of course not an ideal scenario. This PR filters the query fetching these parameters to avoid this happening.
Fixes #19391