Follow-up on PDO and libpq Bug

Posted on April 18, 2008

A while back i blogged about a bug with PDO and prepared statements. After digging a little it appears that as of libpq.so.4 (PostgreSQL 8.0 tree) native prepared statement support was added. If PDO detects you have libpq.so.4 at compile time it will use the libpq prepare instead of its own internal prepare. What then happens is random prepared statements fail with heavy use. Again the only way around this right now is to use libpq.so.3 from PostgreSQL 7.4. Now to figure out who to bug about it. I have a feeling the PDO folks will point to libpq and the libpq maintainers will point to PDO.

Filed under: PostgreSQL | Tagged with: PDO PHP PostgreSQL  | 7 comments

Comments
  1. Tom Lane – April 18, 2008 @ 10:07 PM
    Uh, define "fail"?
  2. Gavin – April 18, 2008 @ 10:24 PM
    Hey Tom, from the other post on it: 
    ERROR:  prepared statement "pdo_pgsql_stmt_b6dc71e8" does not exist
    These happen randomly and often for the same query that otherwise runs fine via libpq.so.3. Also I should be clear it's a general bug not specific to any one query type.
  3. Greg – April 19, 2008 @ 12:16 AM
    Going back to 7.4 libraries seems severe. Surely PDO has an equivalent to $dbh->{pg_server_prepare} = 0 until a proper fix can be made? As a heavy libpq driver developer, I can assure you that this is a PDO problem, not a libpq one. :)
  4. Rasmus – April 19, 2008 @ 07:49 AM
    Perhaps you guys could have a look at what might be wrong with how PDO is talking to libpq then? The source is here: http://cvs.php.net/viewvc.cgi/php-src/ext/pdo_pgsql/pgsql_statement.c See the blocks of code inside the #if HAVE_PQPREPARE sections
  5. Gavin – April 19, 2008 @ 10:39 AM
    I misspoke when I said heavy use, I recalled that what made me look more into this was it was happening on a very low use internal website I setup on a new machine that was using libpq from 8.3.1.
  6. Greg – April 19, 2008 @ 08:50 PM
    Rasmus: I don't know if it's a problem with how PDO is talking to libpq, per se, by their might be some unwarranted assumptions in there. Does every database /connection/ get its own stmt object? The error is being caused from one of three things: 1) Something is deallocating the statement too early. Unlikely, as I do not see any deallocates in the code, and the S->stmt_name = NULL parts seem traightforward enough. 2) The wrong name is being built. Seems very unlikely, as it's being derived from the hex value of the stmt struct, which is also what holds the statement name, and that's used to determine if PQexecPrepared gets fired or if we fall through to a PQexec. 3) The database connections (sessions) are swapping around database/statement handles with impunity. Since prepared statements are not visible to other sessions, this should not be allowed. Seems the most likely, but I don't know enough about PDO to debug. Is there perhaps a document that describes how PDO works in the context of PHPs shared sessions? I presume at a high level PDO is similar to DBI. Rasmus/Gavin, you might want to take this up on the pgsql-interfaces list, as this is getting a bit long for a blog comment section :)
  7. Anton Zalutsky – May 01, 2008 @ 07:38 AM
    Hello Gavin, I see that your are chief technical officer of myyearbook.com I am currently looking to develop a social network myself and was curious if you were interested or could recommend someone for me? I live in Bethlehem, PA Interestingly enough, I know Dave from a camp we both went to way back in the day. If you are at all interested in helping please email me, azalutsky@gmail.com Sincerely, Anton Zalutsky
Post a comment
Comment