pg_send_query_params返回TRUE但失败

Question

I have a PHP script which inserts a row into a Postgres DB. It works fine on my test server (Postgres 9.1) but fails on my new shared host (Postgres 8.4).

$query = "INSERT INTO " . $table . " VALUES (DEFAULT, $1, $2, CURRENT_TIMESTAMP::TIMESTAMP(0), $3, $4, ST_Point($4, $3))";
$result = pg_send_query_params($dbconn, $query, array($is_happy, $rate, $lat, $lon));

The $result is always TRUE but no row is inserted.

I also tried:

$result = pg_get_result($dbconn);

But experienced the same behaviour.

Following @CraigRinger's transaction suggestion below I also tried both:

$query = "BEGIN;INSERT INTO " . $table . " VALUES (DEFAULT, $1, $2, CURRENT_TIMESTAMP::TIMESTAMP(0), $3, $4, ST_Point($4, $3));COMMIT;";
$result = pg_send_query_params($dbconn, $query, array($is_happy, $rate, $lat, $lon));

and

pg_send_query($dbconn, "BEGIN;");
$query = "INSERT INTO " . $table . " VALUES (DEFAULT, $1, $2, CURRENT_TIMESTAMP::TIMESTAMP(0), $3, $4, ST_Point($4, $3));";
$result = pg_send_query_params($dbconn, $query, array($is_happy, $rate, $lat, $lon));
pg_send_query($dbconn, "COMMIT;");

And still got the same behaviour.

If I run the INSERT query in phpPgAdmin a row is inserted. I am also able to get the results from this query in a PHP script:

"SELECT relid FROM pg_stat_user_tables"

What does this mean when the INSERT query result is true but no row is inserted? What could be the problem and how might I approach resolving this?

Edit

I can INSERT rows using phpPgAdmin and then SELECT these rows from a PHP script.

Here is a full PHP script that fails (it is stripped of POST gathering and validation that exists in my full script). The rest.php script simply holds connection vars and a response function. This rest.php script works with my SELECT script:

<?php
require "KLogger.php";
require "rest.php";

ini_set("error_reporting", E_ALL ^ E_NOTICE);
ini_set("display_errors", 0);
ini_set("log_errors", 1);

$log   = KLogger::instance(dirname(__FILE__), KLogger::DEBUG);
$log_id = "AM".time();
$log->logInfo($log_id . " *** " . $_SERVER['REMOTE_ADDR']);

$lat = '51.510199';
$lon = '-0.129654';
$rate = '10';
$is_happy = 't';

$dbconn = pg_connect("host=" . $host . " dbname=" . $db . " user=" . $user . " password=" . $pw);
if(!$dbconn)
{
    $log->logInfo($log_id . " No connection: " . pg_last_error());
    sendResponse(500, "Internal Server Error");
}
else
{
    $query = "INSERT INTO " . $table . " VALUES (DEFAULT, $1, $2, CURRENT_TIMESTAMP::TIMESTAMP(0), $3, $4, ST_Point($4, $3));";
    $result = pg_send_query_params($dbconn, $query, array($is_happy, $rate, $lat, $lon));
    if(!$result)
    {
        $log->logInfo($log_id . " No Result: " . pg_last_error());
        sendResponse(500, "Internal Server Error");
    }
    else
    {
        $log->logInfo($log_id . " sendResponse(200)");
        sendResponse(200, "OK");
    }
}
pg_close($dbconn);
?>

Answer 1

The most common cause for this kind of issue is an open, uncomitted transaction.

If you BEGIN (or do so implicitly by turning autocommit off in your database driver) then do some work, only the transaction that did the work can see the changes until it COMMITs.

If that is the case then an immediate follow-up query from within the same script using the same connection will see the changed row, but nothing else will.

You can also check for this by enabling:

log_statement = 'all'
log_line_prefix = 'db=%d pid=%p vtxid=%v txid=%x'

and finding mismatched transactions by looking for virtual transaction IDs (vtxid) with a BEGIN and no matching COMMIT.

If you can't modify postgresql.conf because it's shared hosting you should be able to ALTER USER myuser SET log_statement = 'all'; or ALTER DATABASE mydatabase SET log_statement = 'all';. You can't set log_line_prefix outside postgresql.conf but your host might have a reasonable setting already.

---

Another possibility - and one that might be explained by the version difference - is that you're triggering an error later in the transaction by using a feature only available in 9.1, and you aren't detecting that error. Your earlier INSERT succeeds, but the whole transaction then gets rolled back when the later statement fails. Again, examine the server logs to see.

---

Another common cause is that you're connecting to a different database with the script than the one you connect to when you test to see if it's inserted. Try SELECTing the row you expect to have been inserted from the script after you insert it. It's also worth creating a dummy table via your admin tool (phpPgAdmin in your case, it seems) and then testing to see whether the script can see the dummy table.