A few possible optimizations for pg_upgrade
@stanhu @twk3 preparing for the DEV upgrade, I looked at the process implementation here and I wonder if can improve it a little bit (moving somewhat from the end backwards; sorry not proposing an MR -- I could but don't have things configured to test myself; and the changes proposed are actually quite simple in terms of code):
- Post-upgrade
ANALYZE
in https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/files/gitlab-ctl-commands/pg-upgrade.rb#L600 we use options-j2 --all --analyze-in-stages
, thoughts:- if we do it during maintenance window, it makes little sense to use the "in stages" option since it will just make the process longer (actually, we don't use it for gprd too, since, historically, the stats with low number of buckets proven to be not really helpful anyway)
-
-j2
, too, can be improved – ideally, if we're inside maintenance window, we should go with "full speed". For example, using the number of available vCPUs here (this is what we do for gprd upgrades too)
-
--link
forpg_upgrade
is quite reliable these days, I would use it. Especially if we have backup anyway. - Noticed that when we run
vacuumdb
ANALYZE, we have have arescue
block https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/files/gitlab-ctl-commands/pg-upgrade.rb#L603, assuming that this operation can fail, with suggestion to report it. I didn't find a similar thing forpg_upgrade
-- but it can fail too, and it's more "heavy" operation, so would make sense to have a similar block for it too? - Last but not least: it could be definitely good to have
pg_upgrade --check
for dry run (it seems it's not implemented -- checked both source code and docs), it can help to identify issues before actual run, it was very helpful for gstg and gprd upgrades – here is how we used it there: https://gitlab.com/gitlab-com/gl-infra/db-migration/-/blob/master/pg-upgrade-logical/roles/upgrade/tasks/upgrade_check.yml#L40.