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

Enable in-database configuration for pool settings #3110

Open
steve-chavez opened this issue Dec 13, 2023 · 3 comments · May be fixed by #3137
Open

Enable in-database configuration for pool settings #3110

steve-chavez opened this issue Dec 13, 2023 · 3 comments · May be fixed by #3137
Labels
config related to the configuration options difficulty: hard Haskell + PostgreSQL + knowledge of PostgREST codebase + unclear design enhancement a feature, ready for implementation

Comments

@steve-chavez
Copy link
Member

Problem

Currently the following settings have no in-db option:

So whenever they need to be updated the postgrest.service (if using systemd) has to be restarted. During this lapse Nginx (or other proxy) will give uninformative error messages like An invalid response was received from the upstream server.

Solution

Enable in-db options for the above configs. While there will be some downtime during the pool restart, we can give a better error message and include a Retry-After header.

@steve-chavez steve-chavez added enhancement a feature, ready for implementation config related to the configuration options difficulty: hard Haskell + PostgreSQL + knowledge of PostgREST codebase + unclear design labels Dec 13, 2023
@steve-chavez steve-chavez added difficulty: medium Haskell task involving PostgreSQL IO and removed difficulty: hard Haskell + PostgreSQL + knowledge of PostgREST codebase + unclear design labels Dec 28, 2023
@wolfgangwalther
Copy link
Member

Isn't this what signal based config reloading is meant for?

Adding config settings which could potentially break the database connection when changed to wrong values to in-db configuration... is something that I would like to avoid, because you can't recover from it via database anymore.

@steve-chavez
Copy link
Member Author

I get the point, that's why db-uri shouldn't be an in-db config for example.

https://postgrest.org/en/stable/references/configuration.html#db-pool-acquisition-timeout
https://postgrest.org/en/stable/references/configuration.html#db-pool-max-idletime
https://postgrest.org/en/stable/references/configuration.html#db-pool-max-lifetime

The above seem completely safe to me in that regard.

https://postgrest.org/en/stable/references/configuration.html#db-pool

Would a large db-pool prevent from recovering via in-db? Hm, it doesn't look like that to me.

Now a negative or 0 db-pool could be unrecoverable but that seems like a separate issue (need to check if there's validation there).

@steve-chavez
Copy link
Member Author

Would a large db-pool prevent from recovering via in-db? Hm, it doesn't look like that to me.

Maybe if it surpasses max_connections? Although that could be validated as well.

@steve-chavez steve-chavez added difficulty: hard Haskell + PostgreSQL + knowledge of PostgREST codebase + unclear design and removed difficulty: medium Haskell task involving PostgreSQL IO labels Jan 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
config related to the configuration options difficulty: hard Haskell + PostgreSQL + knowledge of PostgREST codebase + unclear design enhancement a feature, ready for implementation
Development

Successfully merging a pull request may close this issue.

2 participants