Testing plperl<->plperlu interaction
I was investigating a bug in an 8.4.1 production system and distilled a
test case down to this:
CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to exit(255)
spi_exec_query("invalid sql statement");
$$ language plperl; -- plperl or plperlu
CREATE OR REPLACE FUNCTION foo() RETURNS integer AS $$
spi_exec_query("SELECT * FROM bar()");
return 1;
$$ LANGUAGE plperlu; -- must be opposite to language of bar
SELECT * FROM bar(); -- throws exception normally
SELECT * FROM foo(); -- causes the server to exit abnormaly
before then rereading the 8.4.2 release notes and seeing that the bug
was already fixed. D'oh!
I see the test suite doesn't have any plperlu tests at all.
Is there any reason for that?
Tim.
Tim Bunce wrote:
I was investigating a bug in an 8.4.1 production system and distilled a
test case down to this:CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to exit(255)
spi_exec_query("invalid sql statement");
$$ language plperl; -- plperl or plperluCREATE OR REPLACE FUNCTION foo() RETURNS integer AS $$
spi_exec_query("SELECT * FROM bar()");
return 1;
$$ LANGUAGE plperlu; -- must be opposite to language of barSELECT * FROM bar(); -- throws exception normally
SELECT * FROM foo(); -- causes the server to exit abnormalybefore then rereading the 8.4.2 release notes and seeing that the bug
was already fixed. D'oh!I see the test suite doesn't have any plperlu tests at all.
Is there any reason for that?
Just that we haven't bothered. But we can't run tests for both in the
same session because that doesn't work on all platforms. I actually
played a bit with it the other day. Setting up some plperlu tests would
be very simple.
cheers
andrew
On Jan 6, 2010, at 5:46 PM, Andrew Dunstan wrote:
Tim Bunce wrote:
I was investigating a bug in an 8.4.1 production system and distilled a
test case down to this:CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to exit(255)
spi_exec_query("invalid sql statement");
$$ language plperl; -- plperl or plperlu
CREATE OR REPLACE FUNCTION foo() RETURNS integer AS $$
spi_exec_query("SELECT * FROM bar()");
return 1;
$$ LANGUAGE plperlu; -- must be opposite to language of bar
SELECT * FROM bar(); -- throws exception normally
SELECT * FROM foo(); -- causes the server to exit abnormalybefore then rereading the 8.4.2 release notes and seeing that the bug
was already fixed. D'oh!I see the test suite doesn't have any plperlu tests at all.
Is there any reason for that?Just that we haven't bothered. But we can't run tests for both in the same session because that doesn't work on all platforms. I actually played a bit with it the other day. Setting up some plperlu tests would be very simple.
We've actually run into similar issues. Alvaro came up with a patch that fixes our specific issue, but I think he said there were some other cases that needed to be fixed as well. Anyone looking to fix this should ping Alvaro first.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
decibel wrote:
We've actually run into similar issues. Alvaro came up with a patch
that fixes our specific issue, but I think he said there were some
other cases that needed to be fixed as well. Anyone looking to fix
this should ping Alvaro first.
No, what I fixed was the contrib/xml2 crasher that I still haven't
submitted here (sorry). The plperl fix came from Alexey Klyukin, and
AFAIK the fix is in 8.4.2.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote:
decibel wrote:
We've actually run into similar issues. Alvaro came up with a patch
that fixes our specific issue, but I think he said there were some
other cases that needed to be fixed as well. Anyone looking to fix
this should ping Alvaro first.No, what I fixed was the contrib/xml2 crasher that I still haven't
submitted here (sorry). The plperl fix came from Alexey Klyukin, and
AFAIK the fix is in 8.4.2.
Yes.
[thinks]
Could we have a regression test for it with an alternative result file
for the case where plperl and plperlu are not allowed to run together?
cheers
andrew
On Wed, Jan 06, 2010 at 07:07:12PM -0500, Andrew Dunstan wrote:
Alvaro Herrera wrote:
decibel wrote:
We've actually run into similar issues. Alvaro came up with a patch
that fixes our specific issue, but I think he said there were some
other cases that needed to be fixed as well. Anyone looking to fix
this should ping Alvaro first.No, what I fixed was the contrib/xml2 crasher that I still haven't
submitted here (sorry). The plperl fix came from Alexey Klyukin, and
AFAIK the fix is in 8.4.2.Yes.
[thinks]
Could we have a regression test for it with an alternative result
file for the case where plperl and plperlu are not allowed to run
together?
Or perhaps put the tests that require multiplicity into a plperl_multi.sql
file and add logic to the GNUmakefile to add that file to REGRESS
if "perl -V:usemultiplicity" returns "usemultiplicity='define';"
Tim.
Tim Bunce wrote:
Or perhaps put the tests that require multiplicity into a plperl_multi.sql
file and add logic to the GNUmakefile to add that file to REGRESS
if "perl -V:usemultiplicity" returns "usemultiplicity='define';"
OK, here is a patch that provides for running regression tests for
plperlu alone and plperl/plperlu interaction, skipping the latter if
it's not supported on the platform, using the test Tim has suggested.
cheers
andrew
Attachments:
plperlu-regression.patchtext/x-patch; name=plperlu-regression.patchDownload
Index: GNUmakefile
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plperl/GNUmakefile,v
retrieving revision 1.37
diff -c -r1.37 GNUmakefile
*** GNUmakefile 5 Jun 2009 18:29:56 -0000 1.37
--- GNUmakefile 8 Jan 2010 23:52:30 -0000
***************
*** 38,45 ****
SHLIB_LINK = $(perl_embed_ldflags)
! REGRESS_OPTS = --dbname=$(PL_TESTDB) --load-language=plperl
! REGRESS = plperl plperl_trigger plperl_shared plperl_elog
# where to find psql for running the tests
PSQLDIR = $(bindir)
--- 38,48 ----
SHLIB_LINK = $(perl_embed_ldflags)
! REGRESS_OPTS = --dbname=$(PL_TESTDB) --load-language=plperl --load-language=plperlu
! REGRESS = plperl plperl_trigger plperl_shared plperl_elog plperlu
! ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplicity='define';)
! REGRESS += plperl_plperlu
! endif
# where to find psql for running the tests
PSQLDIR = $(bindir)
Index: expected/plperl_plperlu.out
===================================================================
RCS file: expected/plperl_plperlu.out
diff -N expected/plperl_plperlu.out
*** /dev/null 1 Jan 1970 00:00:00 -0000
--- expected/plperl_plperlu.out 8 Jan 2010 23:52:31 -0000
***************
*** 0 ****
--- 1,18 ----
+ -- test plperl/plperlu interaction
+ CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
+ #die 'BANG!'; # causes server process to exit(2)
+ # alternative - causes server process to exit(255)
+ spi_exec_query("invalid sql statement");
+ $$ language plperl; -- plperl or plperlu
+
+ CREATE OR REPLACE FUNCTION foo() RETURNS integer AS $$
+ spi_exec_query("SELECT * FROM bar()");
+ return 1;
+ $$ LANGUAGE plperlu; -- must be opposite to language of bar
+
+ SELECT * FROM bar(); -- throws exception normally
+ ERROR: syntax error at or near "invalid" at line 4.
+ CONTEXT: PL/Perl function "bar"
+ SELECT * FROM foo(); -- used to cause backend crash
+ ERROR: syntax error at or near "invalid" at line 4. at line 2.
+ CONTEXT: PL/Perl function "foo"
Index: expected/plperlu.out
===================================================================
RCS file: expected/plperlu.out
diff -N expected/plperlu.out
*** /dev/null 1 Jan 1970 00:00:00 -0000
--- expected/plperlu.out 8 Jan 2010 23:52:31 -0000
***************
*** 0 ****
--- 1,9 ----
+ -- Use ONLY plperlu tests here. For plperl/plerlu combined tests
+ -- see plperl_plperlu.sql
+ --
+ -- Test compilation of unicode regex - regardless of locale.
+ -- This code fails in plain plperl in a non-UTF8 database.
+ --
+ CREATE OR REPLACE FUNCTION perl_unicode_regex(text) RETURNS INTEGER AS $$
+ return ($_[0] =~ /\x{263A}|happy/i) ? 1 : 0; # unicode smiley
+ $$ LANGUAGE plperlu;
Index: sql/plperl_plperlu.sql
===================================================================
RCS file: sql/plperl_plperlu.sql
diff -N sql/plperl_plperlu.sql
*** /dev/null 1 Jan 1970 00:00:00 -0000
--- sql/plperl_plperlu.sql 8 Jan 2010 23:52:31 -0000
***************
*** 0 ****
--- 1,17 ----
+ -- test plperl/plperlu interaction
+
+ CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
+ #die 'BANG!'; # causes server process to exit(2)
+ # alternative - causes server process to exit(255)
+ spi_exec_query("invalid sql statement");
+ $$ language plperl; -- plperl or plperlu
+
+ CREATE OR REPLACE FUNCTION foo() RETURNS integer AS $$
+ spi_exec_query("SELECT * FROM bar()");
+ return 1;
+ $$ LANGUAGE plperlu; -- must be opposite to language of bar
+
+ SELECT * FROM bar(); -- throws exception normally
+ SELECT * FROM foo(); -- used to cause backend crash
+
+
Index: sql/plperlu.sql
===================================================================
RCS file: sql/plperlu.sql
diff -N sql/plperlu.sql
*** /dev/null 1 Jan 1970 00:00:00 -0000
--- sql/plperlu.sql 8 Jan 2010 23:52:31 -0000
***************
*** 0 ****
--- 1,10 ----
+ -- Use ONLY plperlu tests here. For plperl/plerlu combined tests
+ -- see plperl_plperlu.sql
+
+ --
+ -- Test compilation of unicode regex - regardless of locale.
+ -- This code fails in plain plperl in a non-UTF8 database.
+ --
+ CREATE OR REPLACE FUNCTION perl_unicode_regex(text) RETURNS INTEGER AS $$
+ return ($_[0] =~ /\x{263A}|happy/i) ? 1 : 0; # unicode smiley
+ $$ LANGUAGE plperlu;
Andrew Dunstan <andrew@dunslane.net> writes:
OK, here is a patch that provides for running regression tests for
plperlu alone and plperl/plperlu interaction, skipping the latter if
it's not supported on the platform, using the test Tim has suggested.
! ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplicity='define';)
! REGRESS += plperl_plperlu
! endif
Hm ... I wonder how badly this fails if perl isn't present?
Before you say that that won't matter, consider "make clean" etc.
The makefile does have to parse.
It might be sufficient to wrap this test in an "ifneq ($(PERL),)"
or similar.
Also, some commentary connecting this test to plperl.c's support for
two interpreters would be a good thing.
regards, tom lane
Tom Lane wrote:
Hm ... I wonder how badly this fails if perl isn't present?
Before you say that that won't matter, consider "make clean" etc.
The makefile does have to parse.It might be sufficient to wrap this test in an "ifneq ($(PERL),)"
or similar.
OK, can do that.
Also, some commentary connecting this test to plperl.c's support for
two interpreters would be a good thing.
ITYM in the .sql file(s)?
I also see that I'll have to make a small adjustment in the MSVC build
programs.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Also, some commentary connecting this test to plperl.c's support for
two interpreters would be a good thing.
ITYM in the .sql file(s)?
No, the test in the makefile is what seems to need a comment. It
doesn't have to be much. I was thinking something like
# if Perl can support two interpreters, test plperl-and-plperlu cases
ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplicity='define';)
BTW, what about the MSVC scripts?
regards, tom lane
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Also, some commentary connecting this test to plperl.c's support for
two interpreters would be a good thing.ITYM in the .sql file(s)?
No, the test in the makefile is what seems to need a comment. It
doesn't have to be much. I was thinking something like# if Perl can support two interpreters, test plperl-and-plperlu cases
ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplicity='define';)
OK
BTW, what about the MSVC scripts?
Yes, I will fix vcregress.pl.
cheers
andrew