Thread: Testing plperl<->plperlu interaction

Testing plperl<->plperlu interaction

From
Tim Bunce
Date:
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(); --
throwsexception 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.


Re: Testing plperl<->plperlu interaction

From
Andrew Dunstan
Date:

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 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?
>
>
>   

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


Re: Testing plperl<->plperlu interaction

From
decibel
Date:
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 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?
>>
>>
>>
>
> 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
therewere 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




Re: Testing plperl<->plperlu interaction

From
Alvaro Herrera
Date:
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.


Re: Testing plperl<->plperlu interaction

From
Andrew Dunstan
Date:

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


Re: Testing plperl<->plperlu interaction

From
Tim Bunce
Date:
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.


Re: Testing plperl<->plperlu interaction

From
Andrew Dunstan
Date:

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
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;

Re: Testing plperl<->plperlu interaction

From
Tom Lane
Date:
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


Re: Testing plperl<->plperlu interaction

From
Andrew Dunstan
Date:
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


Re: Testing plperl<->plperlu interaction

From
Tom Lane
Date:
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


Re: Testing plperl<->plperlu interaction

From
Andrew Dunstan
Date:

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