Skip site navigation (1) Skip section navigation (2)

Re: BUG #2236: extremely slow to get unescaped bytea data

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
You guys are smart!

Apache was running against an old libpq.  I shutdown apache, updated 
/etc/ with the postgres lib dir, ran ldconfig, restarted 
apache, and the problem went away.

The old libpq was (pre-installed on machine).  The new one 
is (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
> linked against different versions of libpq; that would
>add weight to Tom's suggestion that an old libpq might be responsible.

In response to

pgsql-bugs by date

Next:From: Kris JurkaDate: 2006-02-10 08:15:25
Subject: Re: BUG #2250: JSTL parameterized queries inserting numeric
Previous:From: Michael FuhrDate: 2006-02-09 15:58:57
Subject: Re: BUG #2236: extremely slow to get unescaped bytea data

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group