Thread: trouble making PG use my Perl
We're trying to upgrade our Pg 9.6 installs up to 12.2. In a break from tradition where we grab source and compile our own, I've downloaded the community RPMs for Centos 6 and installed them (they default into /usr/pgsql-12 it seems).
I can make Pg come up, initdb, that sort of stuff just fine. But we also use the Perl extension and we have references to Perl modules that are in *our* Perl and not the system one. Yes, we compile our own Perl like we provide our own Pg because Centos uses much older versions.
The issue is that I've not been able to make Pg use our Perl (in /opt/perl) instead of the system one (in /usr). I've tried changing the env-vars in multiple places, the most obvious being the /etc/init.d script, but none of that helps. When we compiled our own Pg, I could set this with "export PERL=/opt/perl/bin/perl" before the "configure --with-perl" command. Setting PERL in the init.d file doesn't help either.
Sadly, I can't find anything about this in the docs. Searching online doesn't turn up anything either as the search terms are too generic (or I can't find a way to make them specific enough to help). Haven't found any options for postgresql.conf either.
So how does one set the Perl binary/library at server start time?
Am I going to have to compile my own Pg again to make this work?
Thanks,
Kevin
Kevin Brannen <KBrannen@efji.com> writes:
> The issue is that I've not been able to make Pg use our Perl (in
> /opt/perl) instead of the system one (in /usr).
plperl.so will typically have a more or less hard-coded path to
libperl.so, eg
$ ldd ...installdir.../lib/plperl.so
linux-vdso.so.1 => (0x00007ffc613cf000)
libperl.so => /usr/lib64/perl5/CORE/libperl.so (0x00007fa315d48000)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa315b11000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa31577d000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fa315563000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fa315349000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fa315145000)
libm.so.6 => /lib64/libm.so.6 (0x00007fa314ec1000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fa314c89000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fa314a86000)
/lib64/ld-linux-x86-64.so.2 (0x000055646d09b000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007fa314883000)
You might be able to override that with LD_LIBRARY_PATH, but it's
a pain, and it will certainly not work if your homebrew libperl
isn't 100% ABI-compatible with the system one.
Personally I'd build plperl against the Perl you want to use it with.
The rest of PG isn't dependent on Perl, so you could use the community
install for the rest of it if you like.
regards, tom lane
From: Tom Lane <tgl@sss.pgh.pa.us> >Kevin Brannen <KBrannen@efji.com> writes: >> The issue is that I've not been able to make Pg use our Perl (in >> /opt/perl) instead of the system one (in /usr). > >plperl.so will typically have a more or less hard-coded path to libperl.so, eg > >$ ldd ...installdir.../lib/plperl.so > linux-vdso.so.1 => (0x00007ffc613cf000) > libperl.so => /usr/lib64/perl5/CORE/libperl.so (0x00007fa315d48000) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >You might be able to override that with LD_LIBRARY_PATH, but it's a pain, and it will certainly not work if your homebrewlibperl isn't 100% ABI-compatible with the system one. > >Personally I'd build plperl against the Perl you want to use it with. >The rest of PG isn't dependent on Perl, so you could use the community install for the rest of it if you like. > >regards, tom lane Thanks Tom, I can see your point. With the right change to LD_LIBRARY_PATH, I can make `ldd plperl.so` point to my Perl, but as you say, I'm probably playing with fire to expect it all to be 100% compatible between Perl 5.10.1 (Centos 6 default) and 5.30.1 (mine). It'd be nice if we could set Perl at server start time, but I can see how it might not be possible. I'll see about making this extension versus just recompiling the whole thing. I don't recall building Pg to be all that hard, I was just hoping to avoid it. -OR- I blast it from orbit and rewrite the 2 plperl functions so I don't need the extension. Decisions ... decisions ... Thanks! Kevin This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information.If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, youare hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attachedto this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notifyus by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them todisk. Thank you.
> I can make Pg come up, initdb, that sort of stuff just fine. But we > also use the Perl extension and we have references to Perl modules > that are in *our* Perl and not the system one. Yes, we compile our > own Perl like we provide our own Pg because Centos uses much older > versions. > > The issue is that I've not been able to make Pg use our Perl > (in /opt/perl) instead of the system one (in /usr). I've tried > changing the env-vars in multiple places, the most obvious being > the /etc/init.d script, but none of that helps. When we compiled our > own Pg, I could set this with "export PERL=/opt/perl/bin/perl" before > the "configure --with-perl" command. Setting PERL in the init.d file > doesn't help either. If you use the centos pre-compiled glob then you'll get their pre-compiled paths to their pre-compiled Perl which, among other things, is compiled with all optimization turned off, with 5.00503 compatibility turned *on*, and a host of other pure idiocies that make their perl unsuitable for human use. Simplest fix is probably rolling your own: PG's build cycle is quite manageable, as is Perl's, and you'll get something that is reasonably optimized for your platform and use. -- Steven Lembark 3646 Flora Place Workhorse Computing St. Louis, MO 63110 lembark@wrkhors.com +1 888 359 3508
On Thu, 27 Feb 2020 20:42:36 +0000 Kevin Brannen <KBrannen@efji.com> wrote: > Thanks Tom, I can see your point. With the right change to > LD_LIBRARY_PATH, I can make `ldd plperl.so` point to my Perl, but as > you say, I'm probably playing with fire to expect it all to be 100% > compatible between Perl 5.10.1 (Centos 6 default) and 5.30.1 (mine). Note that you don't *want* to be binary compatible with the junk they distribute. Unless you really expect to have copies of 5.00503 running? No, probably not. RH and Debian distros are distriuted by heavy Python users who go out of their way to hamstring Perl at every step. Unless things have changed massively, the Perl they distribute is not only out of date it's nearly broken out of the box. Try running "perl -V" sometime and review the "config_args" values. enjoi -- Steven Lembark 3646 Flora Place Workhorse Computing St. Louis, MO 63110 lembark@wrkhors.com +1 888 359 3508
On Thu, 27 Feb 2020 15:07:29 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > You might be able to override that with LD_LIBRARY_PATH, but it's > a pain, and it will certainly not work if your homebrew libperl > isn't 100% ABI-compatible with the system one. > > Personally I'd build plperl against the Perl you want to use it with. > The rest of PG isn't dependent on Perl, so you could use the community > install for the rest of it if you like. Funny thing is that both PG and Perl are easy enough to build from scratch and the centos compile of Perl at least is both ancient and horrid enough (5.00503 compatibility, really?) that it's easier to just shell-script both builds and run it overnight. Q: How un-optimized and ancient is the PG on centos? -- Steven Lembark 3646 Flora Place Workhorse Computing St. Louis, MO 63110 lembark@wrkhors.com +1 888 359 3508
On 2020-02-28 07:13:12 -0600, Steven Lembark wrote:
> If you use the centos pre-compiled glob then you'll get their
> pre-compiled paths to their pre-compiled Perl which, among
> other things, is compiled with all optimization turned off,
> with 5.00503 compatibility turned *on*, and a host of other
> pure idiocies that make their perl unsuitable for human use.
I don't have access to a current CentOS, but both claims are wrong for
even the ancient RHEL 6 systems we still have around for some reason.
I find it hard to believe that someone would find it necessary to turn
on bincompat5005 in 2019 when they already considered that obsolete in
2010.
Same for optimization. There are some optimizations that a general
purpose binary distribution like RHEL can't do (like optimizing for a
specific processor type), but frankly I doubt that perl's Configure
turns them on.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachment
On 2020-02-28 07:17:27 -0600, Steven Lembark wrote:
> RH and Debian distros are distriuted by heavy Python users who
> go out of their way to hamstring Perl at every step.
That's just complete bullshit, at least for Debian (I don't have current
experience with Redhat). The maintainer system makes that very unlikely.
> Unless things have changed massively, the Perl they distribute is not
> only out of date it's nearly broken out of the box.
I have been programming in Perl for 25 years, much of that time on
Redhat and Debian systems. Perl was sometimes a bit out of date (usually
because the OS was a bit out of date - that's the price you pay for
stability), but never as much as on commercial Unixes like HP-UX or
Solaris, and it was never broken. I have occasionally compiled perl
myself, usually because I wanted to try out some new features, sometimes
because I tried to make it faster. But for production use I've almost
always used the system-supplied perl.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachment
From: Steven Lembark <lembark@wrkhors.com> >Funny thing is that both PG and Perl are easy enough to build from scratch and the centos compile of Perl at least is bothancient and horrid enough (5.00503 compatibility, really?) that it's easier to just shell-script both builds and runit overnight. >Q: How un-optimized and ancient is the PG on centos? I agree that it's not all that hard to compile my own Perl and Pg; I've done it in the past. That being said, I'd preferto avoid it and now I can avoid compiling Pg. On Centos 6.10, it ships with Perl 5.10.1, which is really ancient to me. Centos 8 ships with 5.14 (IIRC). Still pretty badand it makes me like your conspiracy theory about Python folks ignoring it on purpose. 😊 They do compile with -O2 andMULTIPLICITY, so it's not too bad. In the end, I found there were only 2 plperlu functions. Turns out 1 wasn't even used anymore (gotta love legacy code) andthe other function was only called in 1 place, so it was moved into a module and adjusted (spi_* calls turned into DBIcalls, etc). After that, there was no more reason for the plperlu extension so the problem no longer matters and I canload 1 less rpm. I find it a shame we can't just swap Perl libraries, but I can understand why when I stop to really think about it. Kevin This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information.If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, youare hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attachedto this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notifyus by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them todisk. Thank you.
Kevin Brannen <KBrannen@efji.com> writes:
> On Centos 6.10, it ships with Perl 5.10.1, which is really ancient to
> me.
Well, yeah, because RHEL 6/Centos 6 are really ancient. That's what
I'd expect with a long-term-support distro that's nearly EOL.
Replacing its Perl version would go against the whole point of
an LTS distro.
> Centos 8 ships with 5.14 (IIRC).
I don't have an actual Centos 8 machine handy to disprove that,
but the info I have says that RHEL8/Centos 8 branched off from
Fedora 28, and F28 most definitely shipped with Perl 5.26.
Looking at their git repo, the last few Fedora releases
shipped with
f23 5.22.2
f24 5.22.4
f25 5.24.3
f26 5.24.4
f27 5.26.2
f28 5.26.3
f29 5.28.2
f30 5.28.2
f31 5.30.1
f32 5.30.1
which so far as I can tell is tracking Perl releases pretty promptly
(keep in mind Fedora releases are on a six-month cadence). In the
Red Hat world, if you want bleeding edge you should be using Fedora.
RHEL/Centos are for people who want to set up a server and have a
reasonably stable software environment for five or ten years.
> Still pretty bad and it makes me like your conspiracy theory about
> Python folks ignoring it on purpose.
As an ex-Red-Hat employee, I am used to but nonetheless tired of
Red Hat haters. If you don't like their distro, fine, but don't
spread demonstrably false misinformation about it.
regards, tom lane
On Mon, 2020-03-02 at 18:23 -0500, Tom Lane wrote:
Kevin Brannen <KBrannen@efji.com> writes:On Centos 6.10, it ships with Perl 5.10.1, which is really ancient tome.Well, yeah, because RHEL 6/Centos 6 are really ancient. That's whatI'd expect with a long-term-support distro that's nearly EOL.Replacing its Perl version would go against the whole point ofan LTS distro.Centos 8 ships with 5.14 (IIRC).I don't have an actual Centos 8 machine handy to disprove that,but the info I have says that RHEL8/Centos 8 branched off fromFedora 28, and F28 most definitely shipped with Perl 5.26.Looking at their git repo, the last few Fedora releasesshipped with
I can confirm that CentOS 8 has perl 5.26.3.
From: Alan Hodgson <ahodgson@lists.simkin.ca>
On Mon, 2020-03-02 at 18:23 -0500, Tom Lane wrote:
Kevin Brannen <Centos 8 ships with 5.14 (IIRC).I don't have an actual Centos 8 machine handy to disprove that,but the info I have says that RHEL8/Centos 8 branched off fromFedora 28, and F28 most definitely shipped with Perl 5.26.Looking at their git repo, the last few Fedora releasesshipped with
> I can confirm that CentOS 8 has perl 5.26.3.
{fires up the C8 VM…}
Yes, you're correct. My memory failed me there. ☹
I must have been thinking of Centos 7, which is 5.16.3 and feels old too -- though to be fair C7 came out quite some time ago.
Kevin