revert-pg-upgrade does not fail gracefully if you forget tmp-dir
If you originally used --tmp-dir
option on pg-upgrade
and forget to use it on revert-pg-upgrade
it goes way too fast for you to notice and stop it. Running it again with the --tmp-dir
results in a failure because it thinks it's already in the right state. Also if it cannot find the backup (when running revert-pg-upgrade
) I think it should just quit all together because after this you end up in a state where nothing works. If it was a revert during the initially pg-upgrade
and the original data has not been converted then the current method might make sense.
[user@gitlabdev1 /]$ sudo gitlab-ctl revert-pg-upgrade
Toggling deploy page:cp /opt/gitlab/embedded/service/gitlab-rails/public/deploy.html /opt/gitlab/embedded/service/gitlab-rails/public/index.html
Toggling deploy page: OK
Toggling services:ok: down: logrotate: 1s, normally up
ok: down: mailroom: 0s, normally up
ok: down: registry: 1s, normally up
ok: down: sidekiq: 1s, normally up
Toggling services: OK
Checking if we need to downgrade: NOT OK
/var/opt/gitlab/postgresql/data.9.2.18 does not exist, cannot revert data
Will proceed with reverting the running program version only, unless you interrupt
Reverting database to 9.2.18 in 5 seconds
=== WARNING ===
This will revert the database to what it was before you upgraded, including the data.
Please hit Ctrl-C now if this isn't what you were looking for
=== WARNING ===
== Reverting ==
ok: down: postgresql: 0s, normally up
timeout: down: postgresql: 0s, normally up, want up
== Reverted ==
Toggling deploy page:rm -f /opt/gitlab/embedded/service/gitlab-rails/public/index.html
Toggling deploy page: OK
Toggling services:ok: run: logrotate: (pid 19856) 0s
ok: run: mailroom: (pid 19864) 1s
ok: run: registry: (pid 19868) 0s
ok: run: sidekiq: (pid 19880) 1s
Toggling services: OK
Edited by 🤖 GitLab Bot 🤖