Hello, sorry for long absense. As far as I see, on an out-of-memory in getAnotherTuple() makes conn->result->resultStatus = PGRES_FATAL_ERROR and qpParseInputp[23]() skips succeeding 'D' messages consequently.
When exception raised within row processor, pg_conn->inCursor always positioned in consistent and result->resultStatus == PGRES_TUPLES_OK. The choices of the libpq user on that point are, - Continue to read succeeding tuples. Call PQgetResult() to read 'D' messages and hand it to row processor succeedingly. - Throw away the remaining results. Call pqClearAsyncResult() and pqSaveErrorResult(), then call PQgetResult() to skip over the succeeding 'D' messages. (Of course the user can't do that on current implement.) To make the users able to select the second choice (I think this is rather major), we should only provide and export the new PQ* function to do that, I think. void PQskipRemainingResult(PGconn *conn) { pqClearAsyncResult(conn); /* conn->result is always NULL here */ pqSaveErrorResult(conn); /* Skip over remaining 'D' messages. * / PQgetResult(conn); } User may write code with this function. ... PG_TRY(); { ... res = PQexec(conn, "...."); ... } PG_CATCH(); { PQskipRemainingResult(conn); goto error; } PG_END_TRY(); Of cource, this is applicable to C++ client in the same manner. try { ... res = PQexec(conn, "...."); ... } catch (const myexcep& ex) { PQskipRemainingResult(conn); throw ex; } By the way, where should I insert this function ? regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers