On 05/17/2017 01:28 PM, Martin Goodson wrote:
On 17/05/2017 20:11, Adrian Klaver wrote:
I thought you where working on VM you had access/rights to.
That is not the case?
I have sudo access on the redhat box we're working on so technically I
could do this, yup. But whilst our Unix team are happy for us to do
whatever the heck we like within our own domain (so to speak - all the
databases, tools we use, etc), they prefer to retain control over 'top
level' system-admin stuff like disks, the contents of /lib, etc.
I like to keep our sysadmins happy, so I'm going to leave /lib to them :)
Got it.
Whoever does it needs to unlink:
/lib64/libldap_r-2.4.so.2
Got it. We'll see what happens tomorrow. Thank you for all the help so
far, it's been *invaluable*. Hopefully tomorrow I'll have some good news
to report!
btw, if this is a reproducible thing is it worth raising with
enterprisedb or 2nd Quadrant? Is this a 'bug' of some kind, or just a
really weird edge case? :)
I could build repmgr against Postgres source and on Ubuntu install of
EDB Postgres. The issue seems to be a combination of RH and EDB Postgres
installation. To me it looks like ld is finding
/lib64/libldap_r-2.4.so.2 library before the /opt/PostgreSQL/9.6/lib/
one. Removing the link in /lib64/ seems to force it to use the EDB
installed library. I do not know enough about ld to figure out how to
force it to only look at the EDB installed library without removing the
link.
Regards,
Martin.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
