Hi Christoph,
thank you very much for your time.
We know the 2 releases are old, unfortunately we cannot change requirement,
we got this server under our management 3 weeks ago, and customer asked to upgrade urgently to 12.
It's a governement agency, and the limit is due to certification matrix with application running
against the database.
We totaly agree with you about to switch to a new VM built from scratch, but probabiy this wont be possible,
so we need to understand in deep what we could face in the migration step having this server and (we hope) a clone to test on.
thanks again
regards
Marco
Il 02.08.2023 16:57 Christoph Moench-Tegeder ha scritto:
## marco.ptz@tiscali.it (marco.ptz@tiscali.it):
we have recently started to manage a production server running a 9.6 postgres.
Which is EOL for nearly two years now:
https://www.postgresql.org/support/versioning/
We have to upgrade to postgres 12.x
Which is going EOL in little over one year's time.
You should look into https://yum.postgresql.org/packages/where you
can get packages with some real production life time.
At present in /usr/bin there are not links as aspected for use with alternatives, but there are files belonging to 9.2 version except for pg_basebackup:
That sounds severly broken, as if you installed CentOS original
"postgresql" package (CentOS 7 ships with the really ancient 9.2).
Check rpm and yum where that came from and then it's time for some
cleanup. In the mean time, make sure to always call all PostgreSQL
utilities with full path.
Could we have trouble having 9.6 and 12 running in the same time (we will upgrade with pg_upgrade) in such server?
For pg_upgrade, you will need both the old and new binaries installed.
HOW can we to fix the presence of release 9.2 files in /usr/bin?
Maybe best use the upgrade opportunity to move everything to a clean
installation on a new VM?
Will the simbolic links in /usr/bin be created by alternatives once the 9.2 release will be dropped/deinstalled/deleted?
The symlinks would be created by registering the repective versions
with the alternatives system - usually that happens in the post-install
scripts of the RPMs. You could do that manually (after removing 9.2)
or maybe by re-installing your current (ancient) packages. Cleanest
solution would be a new server - who knows what other surprises are
hidden on that machine?
Regards,
Christoph
-- Spare Space.