Обсуждение: Should I care about this error "failed to link /usr/bin/psql [...]exists and it is not a symlink"?
Hi all,
I'm installing postgres 9.6 in a CentOS 7 computer that already has postgres v9.2 installed (version that comes with CentOS installer) and I've seen the message of this mail's subject. It's the second machine where I see it, but previous one was a development server and I passed over it. But now I'm trying to make a guide to take this procedure to a Production server. I understand what this error is telling me, what I'm missing is if this has or can have any side effects.
The full installation log is (sorry for the parts in Spanish but I guess is more or less legible, if translation needed please ask):
[root@test-replicas ~]# yum install postgresql96-server [....] Running transaction check Running transaction test Transaction test succeeded Running transaction Instalando : postgresql96-libs-9.6.16-2PGDG.rhel7.x86_64 1/3 Instalando : postgresql96-9.6.16-2PGDG.rhel7.x86_64 2/3 failed to link /usr/bin/psql -> /etc/alternatives/pgsql-psql: /usr/bin/psql exists and it is not a symlink failed to link /usr/bin/clusterdb -> /etc/alternatives/pgsql-clusterdb: /usr/bin/clusterdb exists and it is not a symlink failed to link /usr/bin/createdb -> /etc/alternatives/pgsql-createdb: /usr/bin/createdb exists and it is not a symlink failed to link /usr/bin/createlang -> /etc/alternatives/pgsql-createlang: /usr/bin/createlang exists and it is not a symlink failed to link /usr/bin/createuser -> /etc/alternatives/pgsql-createuser: /usr/bin/createuser exists and it is not a symlink failed to link /usr/bin/dropdb -> /etc/alternatives/pgsql-dropdb: /usr/bin/dropdb exists and it is not a symlink failed to link /usr/bin/droplang -> /etc/alternatives/pgsql-droplang: /usr/bin/droplang exists and it is not a symlink failed to link /usr/bin/dropuser -> /etc/alternatives/pgsql-dropuser: /usr/bin/dropuser exists and it is not a symlink failed to link /usr/bin/pg_basebackup -> /etc/alternatives/pgsql-pg_basebackup: /usr/bin/pg_basebackup exists and it is not a symlink failed to link /usr/bin/pg_dump -> /etc/alternatives/pgsql-pg_dump: /usr/bin/pg_dump exists and it is not a symlink failed to link /usr/bin/pg_dumpall -> /etc/alternatives/pgsql-pg_dumpall: /usr/bin/pg_dumpall exists and it is not a symlink failed to link /usr/bin/pg_restore -> /etc/alternatives/pgsql-pg_restore: /usr/bin/pg_restore exists and it is not a symlink failed to link /usr/bin/reindexdb -> /etc/alternatives/pgsql-reindexdb: /usr/bin/reindexdb exists and it is not a symlink failed to link /usr/bin/vacuumdb -> /etc/alternatives/pgsql-vacuumdb: /usr/bin/vacuumdb exists and it is not a symlink Instalando : postgresql96-server-9.6.16-2PGDG.rhel7.x86_64 3/3 Comprobando : postgresql96-libs-9.6.16-2PGDG.rhel7.x86_64 1/3 Comprobando : postgresql96-server-9.6.16-2PGDG.rhel7.x86_64 2/3 Comprobando : postgresql96-9.6.16-2PGDG.rhel7.x86_64 3/3 Instalado: postgresql96-server.x86_64 0:9.6.16-2PGDG.rhel7 Dependencia(s) instalada(s): postgresql96.x86_64 0:9.6.16-2PGDG.rhel7 postgresql96-libs.x86_64 0:9.6.16-2PGDG.rhel7 ¡Listo! [root@test-replicas ~]# ls -l /usr/bin/psql /etc/alternatives/pgsql-psql lrwxrwxrwx. 1 root root 23 dic 3 12:37 /etc/alternatives/pgsql-psql -> /usr/pgsql-9.6/bin/psql -rwxr-xr-x. 1 root root 449280 nov 6 2016 /usr/bin/psql
I've searched this error, but the only thing I've found is something about alternatives system, and the command update-alternatives. But I don't fully understand this system (I'm used to Windows) and this means that when using the command I'm not sure about what I'm doing, and I can't go to a Production environment like this. An alternative to this could be copy all these files to another location and replace them with links to the copies. But this solution looks a bit ugly (don't know how to express better :D).
Should I go the easy way (copy files and replace original ones with links), is better the first option (update-alternatives) or is there another solution?
Thank you for your time,
Ekaterina
Ekaterina Amez <ekaterina.amez@zunibal.com> writes:
> I'm installing postgres 9.6 in a CentOS 7 computer that already has
> postgres v9.2 installed (version that comes with CentOS installer) and
> I've seen the message of this mail's subject.
> ...
> failed to link /usr/bin/psql -> /etc/alternatives/pgsql-psql: /usr/bin/psql exists and it is not a symlink
> ...
I believe the issue here is that you've got Red Hat's postgresql packages
installed, and they're not set up to participate in alternatives
switching. I'd suggest removing those packages --- having them installed
alongside PGDG postgres packages is going to lead to nothing but grief.
regards, tom lane
Hi Tom, El 3/12/19 a las 16:14, Tom Lane escribió: > Ekaterina Amez <ekaterina.amez@zunibal.com> writes: >> I'm installing postgres 9.6 in a CentOS 7 computer that already has >> postgres v9.2 installed (version that comes with CentOS installer) and >> I've seen the message of this mail's subject. >> ... >> failed to link /usr/bin/psql -> /etc/alternatives/pgsql-psql: /usr/bin/psql exists and it is not a symlink >> ... > I believe the issue here is that you've got Red Hat's postgresql packages > installed, As I've mentioned, this Postgres version comes with CentOs installation, so I guess you're right. > and they're not set up to participate in alternatives > switching. I'd suggest removing those packages By "removing those packages" you mean uninstall v9.2? This is a test computer and it's not a problem, but I'm afraid this is going to happen also in production server, by doing this won't be my cluster be unavailable? > --- having them installed > alongside PGDG postgres packages is going to lead to nothing but grief. > > regards, tom lane So what's happening is that I have installed a RH version of Postgres instead an official one? Am I right? Regards, Ekaterina
Ekaterina Amez <ekaterina.amez@zunibal.com> writes:
> El 3/12/19 a las 16:14, Tom Lane escribió:
>> I believe the issue here is that you've got Red Hat's postgresql packages
>> installed,
> As I've mentioned, this Postgres version comes with CentOs installation,
> so I guess you're right.
>> and they're not set up to participate in alternatives
>> switching. I'd suggest removing those packages
> By "removing those packages" you mean uninstall v9.2? This is a test
> computer and it's not a problem, but I'm afraid this is going to happen
> also in production server, by doing this won't be my cluster be unavailable?
Um, wait a minute. Are you actually running a server with that 9.2
installation? And the goal is to upgrade that to 9.6 using PGDG
packages? If so, it's going to take some experimentation. I'm sure
that whatever upgrade script the PGDG packages provide isn't going
to work; you'll have to run pg_upgrade by hand. It's probably possible,
but bleats from yum are the least of your worries.
Once you do get the data converted over, probably the cleanest way to
resolve the installation conflict is to remove both sets of packages
and then reinstall only the PGDG ones.
> So what's happening is that I have installed a RH version of Postgres
> instead an official one? Am I right?
That would depend on what you want to call "official" ;-). But Red Hat's
postgres packages use a much different file layout than the PGDG packages,
so they don't interoperate terribly well.
regards, tom lane
Hi Tom, El 3/12/19 a las 17:10, Tom Lane escribió: > Ekaterina Amez <ekaterina.amez@zunibal.com> writes: >> El 3/12/19 a las 16:14, Tom Lane escribió: >>> I believe the issue here is that you've got Red Hat's postgresql packages >>> installed, >> As I've mentioned, this Postgres version comes with CentOs installation, >> so I guess you're right. >>> and they're not set up to participate in alternatives >>> switching. I'd suggest removing those packages >> By "removing those packages" you mean uninstall v9.2? This is a test >> computer and it's not a problem, but I'm afraid this is going to happen >> also in production server, by doing this won't be my cluster be unavailable? > Um, wait a minute. Are you actually running a server with that 9.2 > installation? And the goal is to upgrade that to 9.6 using PGDG > packages? If so, it's going to take some experimentation. I'm sure > that whatever upgrade script the PGDG packages provide isn't going > to work; you'll have to run pg_upgrade by hand. It's probably possible, > but bleats from yum are the least of your worries. > > Once you do get the data converted over, probably the cleanest way to > resolve the installation conflict is to remove both sets of packages > and then reinstall only the PGDG ones. I think it's better to explain my goal... We have a Production server that runs PG9.2 over CentOs 7. The cluster in this server contains several databases, one of them is almost 350GB and growing. This database is being updated almost continuously, mainly by a cron script that runs every 5 minutes and gathers data from other sources and loads it in the db. We want to upgrade this server to 9.6 (it's the target version of other upgrades made in other servers) and, after asking here, I've concluded that it is best to create a hot standby replica of this cluster and, when data is synchronized and tested that everything is fine, stop master and make a pg_upgrade with --link option. In case upgrade goes wrong we have slave server that can be promoted to master. One minor detail is we're running out of space in this server. I've upgraded a couple of servers before (from 8.4 to 9.6), and I've done it via pg_upgrade without --link. I guess this is what you refer when saying "pg_upgrade by hand", so there's no problem with this part. >> So what's happening is that I have installed a RH version of Postgres >> instead an official one? Am I right? > That would depend on what you want to call "official" ;-). But Red Hat's > postgres packages use a much different file layout than the PGDG packages, > so they don't interoperate terribly well. > > regards, tom lane I'm going to test this: having a machine with CentOs7 and Red Hat's postgres v9.2 packages, move /usr/bin files listed in the previous log to another locations, create symlinks to the new location in /usr/bin, and finally install install PGDG 9.6 packages over this configuration. We're not planning to run both versions at the same time. When you say "Red Hat's postgres packages use a much different file layout than the PGDG packages, so they don't interoperate terribly well.", I guess you're talking about the installation, not the structure of the database. If I'm right, there shouldn't be problems with pg_upgrade (I'm worried about data corruption as I'm not sure how to detect it). Would it be possible to install another server with same CentOS but with PGDG packages of postgres 9.2 and create the replica to this server and replaces this one with main server when both are completely synchronized? Kind regards, Ekaterina PS=> If PGDG is not the "official" what is it? :D
Ekaterina Amez <ekaterina.amez@zunibal.com> writes:
> When you say "Red Hat's postgres packages use a much different file
> layout than the PGDG packages, so they don't interoperate terribly
> well.", I guess you're talking about the installation, not the structure
> of the database. If I'm right, there shouldn't be problems with
> pg_upgrade (I'm worried about data corruption as I'm not sure how to
> detect it).
Right, I'm just talking about where they put the installed executables
and libraries. The database data per se should be compatible.
> Would it be possible to install another server with same CentOS but with
> PGDG packages of postgres 9.2 and create the replica to this server and
> replaces this one with main server when both are completely synchronized?
Should work, I think, and that's probably a good idea. PGDG's file layout
supports having both 9.2 and 9.6 installed on the same machine much better
than Red Hat's does.
regards, tom lane