Skip to content
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

Added custom options in postgresql.conf file #277

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

franzhcs
Copy link

@franzhcs franzhcs commented Feb 9, 2018

Allow custom options to be added to postgresql.conf file

This PR allows deploying custom options that are appended to the postgresql.conf file.

Allow custom options to be added to postgresql.conf file
@gclough
Copy link
Collaborator

gclough commented Feb 15, 2019

@ElBryan, I'm of two minds about this. It's nice to be able to add custom options if the template is out of date (for example the recently added "data_sync_retry" parameter... but anything that's not a valid GUC will cause PostgreSQL to fail upon startup.

Isn't it a better option to update the template with any missing parameters?

Do you have an example of how this works, and what it fixes?

@franzhcs
Copy link
Author

@gclough Albeit agreeing with you, I have also to point out that even with the current template failing at choosing the right value for a parameter yields to the same outcome.

One of the parameters I was looking for was pg_stat_statements.track

@gclough
Copy link
Collaborator

gclough commented Feb 25, 2019

@ElBryan , that makes perfect sense. I completely ignored the fact that some extensions have custom GUC's that are not in the standard template.

I get the feeling that these lists could get very long, so should we promote using the dash formatting instead of square brackets? Something like:

postgresql_custom_options:
  - postgresql_custom_option: option_blah_blah
    postgresql_custom_option_value: value_blah_blah

or maybe just a list of tuples to make it less verbose:

postgresql_custom_options:
  - (option_blah_blah, value_blah_blah)

And in the template code, could we use more verbose variable names? ...and spaces around the variable names, to match (mostly) the rest of the role?

{% for option in postgresql_custom_options %}
{% for postgresql_custom_option,postgresql_custom_option_value in option.items() %}
{{ postgresql_custom_option }} = {{ postgresql_custom_option_value }}
{% endfor %}
{% endfor %}

I'm open to ideas, and my only motivation is to make this workable when there are a LOT of parameters.

Finally, could you add in the v10 template code?

Thanks.

Copy link

This pr has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

@github-actions github-actions bot added the stale label Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants