From: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Cc: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
Subject: | Re: BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4 |
Date: | 2010-02-18 18:09:00 |
Message-ID: | 20100218180900.GC373@timac.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Feb 18, 2010 at 10:50:23AM +0000, Tim Bunce wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5334
> Logged by: Tim Bunce
> Email address: Tim(dot)Bunce(at)pobox(dot)com
> PostgreSQL version: 8.4.2
> Operating system: OS X
> Description: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL
> 8.4
> Details:
>
> Version 2.22 of the Perl Safe module breaks PostgreSQL 8.4 (and probably
> earlier versions) that have a default encoding of UTF-8.
>
> Safe 2.2x added extra security for closures created inside Safe but then
> returned and executed from outside Safe (which is what PostgreSQL does).
> These closures are now wrapped so that they are executed with Safe
> restrictions in effect.
>
> This extra security is causing the 'utf8fix' code in PostgreSQL 8.4 to die
> (with the error "'require' trapped by operation mask").
>
> I'm investigating this currently but don't yet have a complete fix. (The
> immediate problem appears to be easily fixed by switching to the simpler
> utf8fix code I added for PostgreSQL 9.0. But a failure still happens if
> warn() is called with utf8 string.)
It took a depressingly large number of intense hours to work out what
was going on and then more to try to work out a relatively clean solution.
The underlying problem is in perl and Safe but sadly there's no
reasonable way to fix Safe such that PostgreSQL would work without
changes.
The attached patch (over REL8_4_STABLE) works around the problem.
The key line is:
*PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
This allows the perl regex logic to call the SWASHNEW method that's
called when information from the Unicode character database is needed.
(The lack of that method was causing the regex logic to think that the
utf8 module wasn't loaded, so it would try to 'require' it but fail due
to the restrictions of the Safe compartment.)
The rest of the patch is updates the surrounding code to the same
simplified 'utf8fix' logic used in PostgreSQL 9.0, and the same Safe
version checks.
Tim.
Attachment | Content-Type | Size |
---|---|---|
REL8_4_STABLE-safe222.patch | text/x-patch | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2010-02-18 18:11:42 | Re: BUG #5333: psql returns 0 on error |
Previous Message | Tim Bunce | 2010-02-18 11:00:05 | BUG #5335: GUC value lost on exception |