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@aklaver.com