-
Notifications
You must be signed in to change notification settings - Fork 0
Allow Any Postgres Params #295
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
Overwriting of default params works as well: Test (Control Plane): spec:
postgresParams:
pgaudit.log: all, -misc
pgaudit.log_parameter: "off" Result (Service Cluster): spec:
postgresql:
parameters:
pgaudit.log: all, -misc
pgaudit.log_catalog: "off"
pgaudit.log_parameter: "off"
pgaudit.log_relation: "on"
shared_buffers: 64MB
shared_preload_libraries: pgaudit Default (Service Cluster): spec:
postgresql:
parameters:
pgaudit.log: ddl
pgaudit.log_catalog: "off"
pgaudit.log_parameter: "on"
pgaudit.log_relation: "on"
shared_buffers: 64MB
shared_preload_libraries: pgaudit |
Setting numeric values as strings seems to work as well: Test (Control Plane): spec:
postgresParams:
max_connections: "1001" Result (Service Cluster): spec:
postgresql:
parameters:
max_connections: "1001" Result (Patroni):
Result (Database Instance):
|
|
||
// setPostgresParams add the provided params to the parameter map | ||
func setPostgresParams(parameters map[string]string, providedParams map[string]string) { | ||
for k, v := range providedParams { |
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.
My feeling is that there should be at least be a denylist of params be configurable which a user cannot override
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.
In the central cloud-api
or locally in each postgreslet/service cluster? Locally is more flexible, but also more difficult to maintain.
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.
unsure about this
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.
implementation wise, locally in a configmap is easier, deployment is done via playbook, so keeping this configmap identical between installation should also be a easy task
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.
I used viper to read a (apparently space-separated) list of blocked values from the environment, convert it into a map for easier use and pass that map along to the code in question. now before setting a given postgres param, we check if is contained in the blocklist. if it is, we simply ignore it.
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.
parameters which are not allowed to change should be considered, at least in a slice in the configmap
No description provided.