Re: Speed dblink using alternate libpq tuple storage - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Speed dblink using alternate libpq tuple storage
Date
Msg-id 20120216.142419.261624207.horiguchi.kyotaro@oss.ntt.co.jp
Whole thread Raw
In response to Speed dblink using alternate libpq tuple storage  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
List pgsql-hackers
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.
(Ofcourse 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


pgsql-hackers by date:

Previous
From: Dann Corbit
Date:
Subject: Re: CUDA Sorting
Next
From: Pavel Golub
Date:
Subject: Re: Google Summer of Code? Call for mentors.