Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Andrew Dunstan [EMAIL PROTECTED] writes: The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. As best I can tell at the moment, I have not tested 5.6.1 with anything later than our 7.2 branch, so I don't know exactly where the breakage slipped in. It may be of long standing. Core was generated by `postgres'. Program terminated with signal 11, Segmentation fault. warning: Can't find file postmaster referenced in dld_list. Reading symbols from /usr/lib/libxnet.1...done. Reading symbols from /usr/lib/libc.1...done. Reading symbols from /usr/lib/libdld.1...done. Reading symbols from /home/postgres/testversion/lib/plperl.sl...done. Reading symbols from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl... done. Reading symbols from /usr/lib/libnsl_s.1...done. Reading symbols from /usr/lib/libM.1...done. Reading symbols from /usr/lib/libsec.1...done. #0 0xc00a02fc in ?? () from /usr/lib/libc.1 (gdb) bt #0 0xc00a02fc in ?? () from /usr/lib/libc.1 #1 0xc6fc3bb4 in ?? () from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #2 0xc6f5a99c in ?? () from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #3 0xc6f570a4 in ?? () from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #4 0xc6f56c88 in ?? () from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #5 0xc0d2b660 in plperl_init_interp () at plperl.c:429 #6 0xc0d2b2bc in _PG_init () at plperl.c:213 #7 0x3ce9f0 in internal_load_library ( libname=0xf8 Address 0xf8 out of bounds) at dfmgr.c:296 #8 0x3ce4a4 in load_external_function (filename=0x4016086c \037(, funcname=0x40062924 , signalNotFound=1 '\001', filehandle=0x7b03bb8c) at dfmgr.c:110 #9 0x1af7fc in fmgr_c_validator (fcinfo=0x4016086c) at pg_proc.c:509 #10 0x3d1a98 in OidFunctionCall1 (functionId=1075185772, arg1=49153) at fmgr.c:1527 #11 0x1af530 in ProcedureCreate ( procedureName=0x401075f8 plperl_call_handler, procNamespace=11, replace=0 '\000', returnsSet=0 '\000', returnType=2280, languageObjectId=13, languageValidator=2247, regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tom Lane reports: The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. Sounds like another good reason to start enforcing a minimum modern Perl version. In the past, I advocated making it a minimum of 5.6, but now I think a minimum of 5.8 is in order. The first version of 5.8 was released in July of 2002, so I don't think we'd be upsetting very many people if we did so. Plus, they'd be potentially dumping core anyway, and our energy is better spent improving Pl/Perl itself at this point rather than tweaking things for old versions of Perl. I don't even think I have a pre 5.8 version around anymore. Would such a requirement cause any problems with packagers? I imagine a perl 5.8 prereq is a common thing these days... - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200712011322 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFHUaaevJuQZxSWSsgRA44LAJ9N47I0bIjjILxkOAAUv1ud0lDPAACdEX1J b3oIV+o0OPrT+RNW03WsGxg= =0I4i -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
I wrote: I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. As best I can tell at the moment, I have not tested 5.6.1 with anything later than our 7.2 branch, so I don't know exactly where the breakage slipped in. It may be of long standing. Actually, libperl seems to dump core in the same place in every PG version, back to and including 7.2, so what seems more likely is that this copy of perl is just plain broken. Since we didn't have any form of regression test for plperl back then, it's entirely possible that I never tested any further than compiling plperl with that setup. So we still need someone to try it with a good copy of 5.6 ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Tom Lane wrote: I wrote: I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. As best I can tell at the moment, I have not tested 5.6.1 with anything later than our 7.2 branch, so I don't know exactly where the breakage slipped in. It may be of long standing. Actually, libperl seems to dump core in the same place in every PG version, back to and including 7.2, so what seems more likely is that this copy of perl is just plain broken. Since we didn't have any form of regression test for plperl back then, it's entirely possible that I never tested any further than compiling plperl with that setup. So we still need someone to try it with a good copy of 5.6 ... OK, I have built a fresh copy of perl 5.6.2 and built and linked HEAD against it. It passes the regression tests and the UTF8 test, and doesn't dump core. This is on FC6/x86_64. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
On Sat, 1 Dec 2007, Tom Lane wrote:
I wrote:
I got around to trying it with a dusty 5.6.1 I have laying about on my
HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps
core deep inside libperl. With or without this patch.
As best I can tell at the moment, I have not tested 5.6.1 with anything
later than our 7.2 branch, so I don't know exactly where the breakage
slipped in. It may be of long standing.
Actually, libperl seems to dump core in the same place in every PG
version, back to and including 7.2, so what seems more likely is that
this copy of perl is just plain broken. Since we didn't have any form
of regression test for plperl back then, it's entirely possible that
I never tested any further than compiling plperl with that setup.
So we still need someone to try it with a good copy of 5.6 ...
I tested cvs head which includes the patch on Solaris 9/SPARC with perl
5.6.1 and it seems to work fine.
Test output attached.
Steve
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
CREATE OR REPLACE FUNCTION test(TEXT) RETURNS bool language plperl as $$
return (shift =~
/[a-z\u0105\u0107\u0119\u0142\u0144ó\u015b\u017a\u017c\u0104\u0106\u0118\u0141\u0143\u015aÓ\u0179\u017b0-9_-]+/i)
|| 0;
$$;
CREATE FUNCTION
select test('depesz');
test
--
t
(1 row)
select test('depesz\u0105\u0107\u0119\u0142');
test
--
t
(1 row)
select test('depesz\u0105\u0107\u0119\u0142$');
test
--
t
(1 row)
select test('dePEsz\u0105\u0106\u0119\u0142$');
test
--
t
(1 row)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: +* Fill in just enough information to set up this perl +* function in the safe container and call it. +* For some reason not entirely clear, it prevents errors that +* can arise from the regex code later trying to load +* utf8 modules. How many versions of Perl have you tried this against? Only one :-( I don't have a farm of perl versions hanging round. That's one of the reasons I asked that people test it. The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I spent an hour wrestling unsuccessfully with it this morning but I don't have more time to spend on it. Systems older than 5.6 don't matter, as we don't do any UTF8 mangling on those. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
On Thu, 29 Nov 2007, Andrew Dunstan wrote: The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I've got a 5.6.1 perl here, but it wasn't built shared, so I can't test plperl. I ran the test case Greg posted to the perl bug tracker and it doesn't fail, so unless you're concerned that your change will break 5.6, then it doesn't look like 5.6 needs a fix. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Andrew Dunstan [EMAIL PROTECTED] writes: + * Fill in just enough information to set up this perl + * function in the safe container and call it. + * For some reason not entirely clear, it prevents errors that + * can arise from the regex code later trying to load + * utf8 modules. How many versions of Perl have you tried this against? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
