feat (config.db): [logs] pass the min log level arg using commands
What kind of change does this PR introduce?
feature
What is the current behavior?
when using cli to work with docker locally postgres container size growth wildly based on the current desired configuration as detailed below:
log_statement='all'log_min_messages='warning'
related: https://github.com/supabase/realtime/issues/231; https://github.com/supabase/supabase/pull/5481; https://github.com/supabase/supabase/issues/5505
What is the new behavior?
- No new behavior by default.
- Devs can opt to change min level of messages from configuration.
Additional context
current version (configured with warning)
I've no screenshots but I've seen the container size growth up to 11GiBs after a few days
configured with fatal
container size

new command

Thanks for the PR! As an alternative, do you know if there's a way to limit Postgres logs to a reasonable size? That way we can alleviate the problem without extending the config.
I think you could incur into something like rotation. This is more typically seen from productive/shared envs though.
Regarding limiting the config to devs from their very own local environments, any chance you guys consider revisiting that idea? I mean, I totally understand you have to keep the right balance but just pushing a bit to see what are the actual possibilities in here.
Please don't hesitate to reject this PR, if this is going against some powerful thesis the team has got on her end.
Hi @ferantivero , appreciate your contribution. We have enabled log rotation in local Postgres. I believe this solves the main problem of logs growing indefinitely.
There's another issue with reducing verbosity of the logs. Adding a min log level config could be one solution. However, I think it's more flexible to expose the log explorer interface so that users can filter by the log level they desire.
If you agree, I will close this PR in favour of the log explorer.
@sweatybridge Is there a way to enable the log explorer during local development? The postgresql logs are still unreadable when realtime is enabled due to the constant printing of huge queries that are polled.