Testing plperl<->plperlu interaction

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

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

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

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