[Dovecot] A questions about consume_results (driver-pgsql.c)
Code
static void consume_results(struct pgsql_db *db) { do { if (!PQconsumeInput(db->pg)) break;
if (PQisBusy(db->pg))
return;
} while (PQgetResult(db->pg) != NULL);
if (PQstatus(db->pg) == CONNECTION_BAD)
io_remove_closed(&db->io);
else
io_remove(&db->io);
db->querying = FALSE;
if (db->queue != NULL && db->connected)
queue_send_next(db);}
This is the only part of the driver-pgsql.c code where a CONNECTION_BAD does not result in driver_pgsql_close being called. This will likely happen after the next query (from queue or a new one) failed because the connection was bad. Is there a reason for this?
Rainer Weikusat rweikusat@mssgmbh.com writes:
static void consume_results(struct pgsql_db *db) { do { if (!PQconsumeInput(db->pg)) break;
if (PQisBusy(db->pg)) return;} while (PQgetResult(db->pg) != NULL);
[...]
On a related note, the PQgetResult documentation
http://www.postgresql.org/docs/8.3/interactive/libpq-async.htmlstates that returned PGresults should be freed with PQclear and the PQclear documentation
http://www.postgresql.org/docs/8.3/interactive/libpq-exec.html#LIBPQ-EXEC-MAINsays You can keep a PGresult object around for as long as you need it; it does not go away when you issue a new command, nor even if you close the connection. To get rid of it, you must call PQclear. Failure to do this will result in memory leaks in your application.
so the code quoted above should result in a memory leak if it ever actually receives a PGresult.
On Thu, 2010-03-25 at 20:04 +0100, Rainer Weikusat wrote:
This is the only part of the driver-pgsql.c code where a CONNECTION_BAD does not result in driver_pgsql_close being called. This will likely happen after the next query (from queue or a new one) failed because the connection was bad. Is there a reason for this?
Maybe it would be ok, but it's a bit risky change. It's possible that closing the connection at that point frees some memory that some code later still tries to use.
Although a quick look at the code shows that it's probably safe.
participants (2)
-
Rainer Weikusat
-
Timo Sirainen