Re: Speed dblink using alternate libpq tuple storage

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