On 10/31/18 3:08 PM, Adrian Klaver wrote:
On 10/31/18 3:03 PM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Andrew Gierth wrote:
What this says is that you somehow have a pg 10.3 binary which has been
compiled with ./configure --datadir=/usr/share/postgresql-10.2
which seems, to say the least, somewhat odd.
Andrew,
Quite odd rather than somewhat odd because the configure options in
the
build script point to version 10.3, not 10.2.
Well there is something strange going. From a previous post:
"
When I run pg_config --configure this is the result:
# ./pg_config --configure
'--prefix=/usr/lib/postgresql/10.2' '--sysconfdir=/etc/postgresql/10.2'
'--includedir=/usr/include' '--datarootdir=/usr/share' '--mandir=/usr/man'
'--docdir=/usr/doc/postgresql-10.3' '--datadir=/usr/share/postgresql-10.2'
'--with-openssl' '--with-tcl' '--with-perl' '--with-python' '--with-libxml'
'--with-libxslt' '--enable-thread-safety'
'--with-system-tzdata=/usr/share/zoneinfo' '--disable-nls'
'--build=i586-slackware-linux' 'build_alias=i586-slackware-linux'
'CFLAGS=-O2 -march=i586 -mtune=i686' 'PKG_CONFIG_PATH=/usr/lib/pkgconfig
"
Note '--docdir=/usr/doc/postgresql-10.3' where everything else is
pointing at 10.2/
Hmm in the build script the difference is:
VERSION=${VERSION:-10.3}
PG_VERSION=${PG_VERSION:-10.3}
--docdir=/usr/doc/$PRGNAM-$VERSION \
--datadir=/usr/share/$PRGNAM-$PG_VERSION \
Wonder where the script is finding PG_VERSION?
Do you have env variable set for that?
pg_config isn't used by the postgres binary to find paths, so
"fixing" it
wouldn't help. The same paths that were compiled into pg_config are
compiled into the postgres binary, and pg_config and postgres contain
the
same relocation logic.
Okay.
I'll check with the SlackBuilds.org postgresql package maintainer and
confirm that re-building and re-installing 10.3 will not adversely affect
the data/ directory. Then I'll re-build and re-install it.
Why it worked flawlessly until today when I modified the
postgresql.conf
file to add access by another host name and then broke is also quite odd.
Thanks,
Rich
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx