Remove PG 9.2 from package with GitLab 10

With GitLab 10 around the corner https://gitlab.com/gitlab-org/gitlab-ce/issues/35547, we should look into removing PG 9.2 from the package.

What things do we need to consider @gitlab-build-team ?

It should just be a matter of ensuring the postgresqlsoftware configuration refers to 9.6.3 and removing the postgresql_newconfiguration.

Need to confirm, but pg_upgrade should exit 0 if it doesn't see the postgresql_newconfiguration.

changed milestone to %10.0

Reasons for removing from 9.2, double checked with Yorick:

• We have a number of checks in place so code deviates based on the PG version both in migrations and runtime logic
• Multiple versions complicate the development process as we now have to support PG 9.2, 9.6 (well technically 9.2+), and MySQL
• PostgreSQL 9.2 is EOL in September
• For those who have trouble with upgrading without downtime, we have a solution: https://docs.gitlab.com/ee/update/upgrading_postgresql_using_slony.html#upgrading-postgresql-using-slony We did this for GitLab.com

/cc @joshlambert

To add to @marin's comments: PostgreSQL 10.0 will be released later this year and I would like GitLab.com to upgrade to this as soon as possible. If we also have to support 9.2 that means Omnibus now has to support 3 versions of PostgreSQL: 9.2, 9.6, and 10.0. Dropping support for 9.6 (so we could do 9.2 and 10.0) isn't any better than dropping support for 9.2 and supporting 9.6 + 10.0.

At a high level, I am totally on board with removing PG 9.2 in 10.0. It's EOL in September, and 10.0 is arriving. We'd also be able to start leveraging PG 9.6 specific features in GitLab more broadly.

The tricky part is managing our customers on pre-9.0 installations. This is because pre-9.0 installations may still be running PG 9.2, and if they directly upgrade to 10.0 the DB will fail.

We still have 17% of our EE customers on a version prior to 9.0, and unfortunately it is quite a long tail. Many of our customers update within 1-2 releases, but the rest tend to languish for quite some time. This essentially means that waiting another month or two will not significantly affect the percentage on <9.0.

Even though it's a small percentage, we need to consider how we should handle people upgrading from 8.x to 10.x. It will only have been ~7 months between final 8.x and now 10.0.

• Is there any way to continue supporting the migration without 9.2 still present? I understand pg upgrade requires both binaries, but just asking the question.
• If someone does upgrade to 10.x while PG is on 9.2, what are their options to recover? Essentially if gitlab-ctl reconfigure detects this, what would our instructions be?
• Is there a way we could set a mandatory interim version to upgrade to, for example via apt-get upgrade? Like if you are on 8.x, you go to <latest 9.x>, then next apt-get upgrade you can go up to 10?

Just trying to understand our options here. I'd rather not fail at the package level, but we similarly really shouldn't leave installations in a broken state.

@joshlambert

I think our best bet is to put a test in preinst of 10.x to ensure that they aren't running PostgreSQL 9.2. If they are, fail the upgrade and advise to install the latest 9.x GitLab and ensure pg-upgrade runs successfully.

Thanks @ibaum, that effectively means apt-get upgrade will stop working for the the gitlab package right? Is there some way in our packaging to tell apt to upgrade to a 9.x version before 10.x? Like some type of "requirements" section that will make 10x irrelevant until they meet it?

If our only real option prior to installation completing is blocking the package:

• Do we have the opportunity with the preinst method to output information on what they should do?
• Is the same behavior also available with RPM?

@joshlambert Correct. And I think this is ok for this specific case.

Like some type of "requirements" section that will make 10x irrelevant until they meet it?

This would not allow us any flexibility. At least with the preinst we can print a message on why. Yes, the same behaviour is available with rpm.

added Scheduled label

Okay sounds good. Just wanted to make sure we examined all possible avenues.

There's a slight issue with preinst failing if PG 9.2 is detected.

Consider this scenario: If user is upgrading from 8.17.8 to 10.0 without upgrading PG, as we planned preinst will fail. But, Debian's maintainer scripts work in a way that it is 8.17.8's postinst that is being called, with an argument abort-upgrade. That means, all that logo and ascii art printing from 8.17.8's postinst will still happen and the error message "Your PG is outdated" may be scrolled up.

TLDR; If preinst fails, older version's postinst gets executed and that prints all those ascii art stuff.

This doesn't come with RPM based ones as in them, if %pre fails, bam! the process aborts.

Reference: https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts

PS: With !1884 (closed) we can prevent this from happening the next time such a scenario occurs.

Thanks @balasankarc, that's a bummer. Can we output the "PG is outdated" message in a more apparent manner perhaps then, since it will get scrolled off? I'm not sure if we can print it out in red, for example or some other alternative.

What would the installation state be, if someone did try to upgrade to 10.0 from 8.17.8? It would essentially be unable to start right until they downgraded to 9.x and let the upgrade continue?

@joshlambert Because this happens in preinst, the package wouldn't even have unpacked. So I guess their existing instance would be working without any issues. But, they should upgrade their PG (which basically means upgrade first to a version where pg-upgrade command exists) if they ever want to upgrade to 10.0 or above.

I will confirm this tomorrow morning.

Thanks @balasankarc - if it is being left in a working state, it would be great if we can tell them as part of the message to upgrade to a 9.x release first.

Yeah. We can definitely say that.

Tested in Ubuntu, Debian and CentOS. Failing pre/preinst script will not affect existing installations as new packages are not even unpacked.

Awesome, thanks @balasankarc

assigned to @ibaum

mentioned in merge request !1888 (merged)

Done in !1888 (merged)

closed