From: | Kalador Tech Support <support(at)kalador(dot)com> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #2236: extremely slow to get unescaped bytea data |
Date: | 2006-02-09 16:40:32 |
Message-ID: | 43EB7080.8060909@kalador.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
You guys are smart!
Apache was running against an old libpq. I shutdown apache, updated
/etc/ld.so.conf with the postgres lib dir, ran ldconfig, restarted
apache, and the problem went away.
The old libpq was libpq.so.3.0 (pre-installed on machine). The new one
is libpq.so.3.2 (installed with 8.0.1)
Sorry for the false alarm - thanks for the help.
Kai Ronan
Technical Support
Kalador Entertainment Inc.
Michael Fuhr wrote:
>On Thu, Feb 09, 2006 at 12:46:46PM -0300, Alvaro Herrera wrote:
>
>
>>I note in the PHP 4 sources that the PQunescapeBytea function seems to
>>have been copied there, "for the benefit of PostgreSQL 7.2 users". It
>>says that it comes from 7.3 but I don't see any sscanf call.
>>
>>There is no PQunescapeBytea call in the whole source that I can see, so
>>my guess is that the libpq function is not called at all. So this may
>>be a PHP bug rather than a Postgres bug.
>>
>>
>
>The OP claimed to be using PHP 5.1.2, which does have a call to
>PQunescapeBytea(), although it also has the old code you're seeing
>and a HAVE_PQUNESCAPEBYTEA macro that determines which to use.
>
>Interesting that the command line php and the Apache module behave
>differently. I wonder if ldd would show the php executable and
>libphp5.so linked against different versions of libpq; that would
>add weight to Tom's suggestion that an old libpq might be responsible.
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2006-02-10 08:15:25 | Re: BUG #2250: JSTL parameterized queries inserting numeric |
Previous Message | Michael Fuhr | 2006-02-09 15:58:57 | Re: BUG #2236: extremely slow to get unescaped bytea data |