Postgres version check - only raise in production #16197
Conversation
The feature is meant to protect users from using a wrong version of external DB. But it also breaks devel setups for anybody using PG9.6+. Thus, changing to only raise in production. Development mode will warn to stderr (not sure about loggers in initializers), but not raise an exception.
|
One thing to note - this won't actually show the message when starting the server (when via I didn't want to hide it completely for devel mode, but if preferred.. |
|
As an aside, I feel like vmdb_database gets in the way for all postgreql upgrades. I don't know who uses it, if anyone, and it is also the slowest primordial seed. |
|
I wonder if we should continue to raise for old versions, but log for new ones in development? I would much rather someone discover issues with newer versions that we should fix vs. hitting issues with old versions that we don't care about. Thoughts? |
|
Good idea, doing that.. :) (And adding a |
Raising only in production makes sense for too new DBs but less so for too old DBs. Split.
|
Some comments on commits https://github.com/himdel/manageiq/compare/034fcdfc200476d56f1b6b02eaa9322511b39ccc~...1266bb59a043b748c35cce3429f550bcce9dc79f config/initializers/postgres_required_versions.rb
|
|
Checked commits https://github.com/himdel/manageiq/compare/034fcdfc200476d56f1b6b02eaa9322511b39ccc~...1266bb59a043b748c35cce3429f550bcce9dc79f with ruby 2.3.3, rubocop 0.47.1, and haml-lint 0.20.0 config/initializers/postgres_required_versions.rb
|
It's ok bot, these are PG version numbers and that's the format PG people know. Move along. Nothing to see here. |
The feature (#16171) is meant to protect users from using a wrong version of external DB.
But it also breaks devel setups for anybody using PG9.6+.
Thus, changing to only raise in production.
Development mode will warn to stderr (not sure about loggers in initializers), but not raise an exception.
Cc @chrisarcand, @carbonin, @Fryguy
@miq-bot add_label core, fine/no