Horton
Menu

Thread

  1. Testing plperl<->plperlu interaction

    Tim Bunce <tim.bunce@pobox.com> — 2010-01-06T23:38:52Z

    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.

  2. Re: Testing plperl<->plperlu interaction

    Andrew Dunstan <andrew@dunslane.net> — 2010-01-06T23:46:53Z

    
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

  3. Re: Testing plperl<->plperlu interaction

    decibel <decibel@decibel.org> — 2010-01-06T23:54:57Z

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

  4. Re: Testing plperl<->plperlu interaction

    Alvaro Herrera <alvherre@commandprompt.com> — 2010-01-07T00:00:04Z

    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.

  5. Re: Testing plperl<->plperlu interaction

    Andrew Dunstan <andrew@dunslane.net> — 2010-01-07T00:07:12Z

    
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

  6. Re: Testing plperl<->plperlu interaction

    Tim Bunce <tim.bunce@pobox.com> — 2010-01-07T10:30:18Z

    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.

  7. Re: Testing plperl<->plperlu interaction

    Andrew Dunstan <andrew@dunslane.net> — 2010-01-08T23:58:27Z

    
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

  8. Re: Testing plperl<->plperlu interaction

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-01-09T01:20:09Z

    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

  9. Re: Testing plperl<->plperlu interaction

    Andrew Dunstan <andrew@dunslane.net> — 2010-01-09T02:21:43Z

    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

  10. Re: Testing plperl<->plperlu interaction

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-01-09T02:34:49Z

    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

  11. Re: Testing plperl<->plperlu interaction

    Andrew Dunstan <andrew@dunslane.net> — 2010-01-09T02:43:34Z

    
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