Re: [HACKERS] Segfault from PL/Perl Returning vstring
On Dec 21, 2009, at 9:04 PM, Andrew Dunstan wrote: I cannot reproduce this. I tested with perl 5.10.1 which is the latest reported stable release at http://www.cpan.org/src/README.html, on an 8.4.2 UTF8 database, and with the same Safe and Encode module versions as above. I've replicated it all the way back to 8.0. I'd be happy to give you a login to my box. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
David E. Wheeler wrote: On Dec 21, 2009, at 9:04 PM, Andrew Dunstan wrote: I cannot reproduce this. I tested with perl 5.10.1 which is the latest reported stable release at http://www.cpan.org/src/README.html, on an 8.4.2 UTF8 database, and with the same Safe and Encode module versions as above. I've replicated it all the way back to 8.0. I'd be happy to give you a login to my box. If a trivial plperl function can crash the server this is surely worth some research. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
David E. Wheeler wrote: At least I think it's a segfault. This function returns a vstring: CREATE OR REPLACE FUNCTION wtf( ) RETURNS text LANGUAGE plperl IMMUTABLE STRICT AS $X$ return $^V; $X$; Here's what happens when I call it: try=# select wtf(); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. ! So I think that it doesn't know what to do with vstrings. They should probably never be returned (they're mostly deprecated), but if they are, they should be cast to text, I think. It's not doing that for me. The plperl code has no way at all of knowing that the bytes you are returning come from $^V. If you really want the version back, do what the perl docs tell you and sprintf the value: andrew=# CREATE OR REPLACE FUNCTION wtf( ) RETURNS text LANGUAGE plperl IMMUTABLE STRICT AS $X$ return sprintf(%vd,$^V); $X$; CREATE FUNCTION andrew=# select wtf(); wtf --- 5.8.8 BTW, this should arguably not be an immutable function. You could replace the perl library, so it's not solely dependent on the input for the result. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
On Dec 21, 2009, at 11:46 AM, Andrew Dunstan wrote: It's not doing that for me. Odd. The plperl code has no way at all of knowing that the bytes you are returning come from $^V. If you really want the version back, do what the perl docs tell you and sprintf the value: It works fine if I return `$^V`. BTW, this should arguably not be an immutable function. You could replace the perl library, so it's not solely dependent on the input for the result. Yeah, that's leftover from trying to troubleshoot another problem. More on that in a bit. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
On mån, 2009-12-21 at 14:46 -0500, Andrew Dunstan wrote: BTW, this should arguably not be an immutable function. You could replace the perl library, so it's not solely dependent on the input for the result. By this logic, no function could be immutable, because you could replace the C library or parts of the kernel. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
Peter Eisentraut wrote: On mån, 2009-12-21 at 14:46 -0500, Andrew Dunstan wrote: BTW, this should arguably not be an immutable function. You could replace the perl library, so it's not solely dependent on the input for the result. By this logic, no function could be immutable, because you could replace the C library or parts of the kernel. *shrug* Maybe, OTOH upgrading perl is not such an unusual operation, and doing so *will* affect this value. It's a bit hard to see why one would want the perl version to be immutable. It doesn't look like it would be much use in an index I think people are generally safer not marking functions immutable unless they actually need them to be. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
On Mon, Dec 21, 2009 at 02:46:17PM -0500, Andrew Dunstan wrote: David E. Wheeler wrote: At least I think it's a segfault. This function returns a vstring: CREATE OR REPLACE FUNCTION wtf( ) RETURNS text LANGUAGE plperl IMMUTABLE STRICT AS $X$ return $^V; $X$; Here's what happens when I call it: try=# select wtf(); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. ! So I think that it doesn't know what to do with vstrings. They should probably never be returned (they're mostly deprecated), but if they are, they should be cast to text, I think. It's not doing that for me. You're using 5.8.8. In 5.10.0 $^V was changed to be an object. I'm working in that area. I'll look into it. Tim. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
On Dec 21, 2009, at 2:13 PM, Tim Bunce wrote:
You're using 5.8.8. In 5.10.0 $^V was changed to be an object.
I'm working in that area. I'll look into it.
While you're at it, I have a new problem:
CREATE OR REPLACE FUNCTION wtf(
expression text
) RETURNS text LANGUAGE plperl AS $$
return {$_[0]};
$$;
try=# select wtf('foo');
wtf
-
{
(1 row)
Note how I don't even get the closing }. This does not happen with PL/PerlU.
The denizens of #postgresql think that there's some sort of issue with Safe and
Encode or Encode::Alias (the latter `require`s Encode in two if its methods).
Can you replicate it? It's driving me absolutely batshit. I'm using Perl
5.10.2, Safe 2.20, and Encode 2.39.
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
On Dec 21, 2009, at 2:34 PM, David E. Wheeler wrote:
On Dec 21, 2009, at 2:13 PM, Tim Bunce wrote:
You're using 5.8.8. In 5.10.0 $^V was changed to be an object.
I'm working in that area. I'll look into it.
While you're at it, I have a new problem:
CREATE OR REPLACE FUNCTION wtf(
expression text
) RETURNS text LANGUAGE plperl AS $$
return {$_[0]};
$$;
try=# select wtf('foo');
wtf
-
{
(1 row)
Note how I don't even get the closing }. This does not happen with
PL/PerlU. The denizens of #postgresql think that there's some sort of issue
with Safe and Encode or Encode::Alias (the latter `require`s Encode in two if
its methods). Can you replicate it? It's driving me absolutely batshit. I'm
using Perl 5.10.2, Safe 2.20, and Encode 2.39.
Also, my encoding is en_US.UTF-8. I think it matter that it's UTF-8, to judge
by the
if (GetDatabaseEncoding() == PG_UTF8)
Block in plperl.c.
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segfault from PL/Perl Returning vstring
David E. Wheeler wrote:
On Dec 21, 2009, at 2:34 PM, David E. Wheeler wrote:
On Dec 21, 2009, at 2:13 PM, Tim Bunce wrote:
You're using 5.8.8. In 5.10.0 $^V was changed to be an object.
I'm working in that area. I'll look into it.
While you're at it, I have a new problem:
CREATE OR REPLACE FUNCTION wtf(
expression text
) RETURNS text LANGUAGE plperl AS $$
return {$_[0]};
$$;
try=# select wtf('foo');
wtf
-
{
(1 row)
Note how I don't even get the closing }. This does not happen with PL/PerlU.
The denizens of #postgresql think that there's some sort of issue with Safe and Encode or
Encode::Alias (the latter `require`s Encode in two if its methods). Can you replicate it?
It's driving me absolutely batshit. I'm using Perl 5.10.2, Safe 2.20, and Encode 2.39.
Also, my encoding is en_US.UTF-8. I think it matter that it's UTF-8, to judge
by the
if (GetDatabaseEncoding() == PG_UTF8)
Block in plperl.c.
I cannot reproduce this. I tested with perl 5.10.1 which is the latest
reported stable release at http://www.cpan.org/src/README.html, on an
8.4.2 UTF8 database, and with the same Safe and Encode module versions
as above.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
