Re: Broken postgres links need to find callers - Mailing list pgsql-general

From Rich Shepard
Subject Re: Broken postgres links need to find callers
Date
Msg-id alpine.LNX.2.20.1810311142570.26169@salmo.appl-ecosys.com
Whole thread Raw
In response to Re: Broken postgres links need to find callers  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Broken postgres links need to find callers  (Adrian Klaver <adrian.klaver@aklaver.com>)
Re: Broken postgres links need to find callers  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-general
On Wed, 31 Oct 2018, Andrew Gierth wrote:

> Is there a pg_config binary in /usr/lib/postgresql/10.3/bin/ and if so,
> what is the output of /usr/lib/postgresql/10.3/bin/pg_config --sharedir

Andrew,

   Yes, pg_config is present but pointing to the wrong directory:
# /usr/lib/postgresql/10.3/bin/pg_config --sharedir
/usr/share/postgresql-10.2

   However, the file dates are that of the upgrade from 10.2 to 10.3:

-rwxr-xr-x 1 root root 7096448 Mar  1  2018 postgres*
lrwxrwxrwx 1 root root       8 Mar  1  2018 postmaster -> postgres*
-rwxr-xr-x 1 root root  514732 Mar  1  2018 psql*

and the postgres version is 10.3:

> Also what is the output of  /usr/lib/postgresql/10.3/bin/postgres -V

# /usr/lib/postgresql/10.3/bin/postgres -V
postgres (PostgreSQL) 10.3

> The most plausible explanation I can see for what you're seeing there is
> that what you have as /usr/lib/postgresql/10.3/bin/postgres is not
> actually the 10.3 binary but rather the 10.2 one. There should be no
> symlinks involved there - the path that is reported in the error message
> is the one that the postgres binary actually did try to open.

   Can pg_config be corrected independent of anything else. That seems to be
where the blockage is found.

Thanks,

Rich


pgsql-general by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Broken postgres links need to find callers
Next
From: Adrian Klaver
Date:
Subject: Re: Broken postgres links need to find callers