Re: Speed dblink using alternate libpq tuple storage

On Wed, Feb 08, 2012 at 02:44:13PM +0900, Shigeru Hanada wrote:
> (2012/02/07 23:44), Marko Kreen wrote:
> > On Tue, Feb 07, 2012 at 07:25:14PM +0900, Shigeru Hanada wrote:
> >> - What is the right (or recommended) way to prevent from throwing
> >> exceptoin in row-processor callback function? When author should use
> >> PG_TRY block to catch exception in the callback function?
> >
> > When it calls backend functions that can throw exceptions?
> > As all handlers running in backend will want to convert data
> > to Datums, that means "always wrap handler code in PG_TRY"?
>
> ISTM that telling a) what happens to PGresult and PGconn when row
> processor ends without return, and b) how to recover them would be
> necessary. We can't assume much about caller because libpq is a client
> library. IMHO, it's most important to tell authors of row processor
> clearly what should be done on error case.

Yes.

> In such case, must we call PQfinish, or is calling PQgetResult until it
> returns NULL enough to reuse the connection? IIUC calling
> pqClearAsyncResult seems sufficient, but it's not exported for client...

Simply dropping ->result is not useful as there are still rows
coming in. Now you cannot process them anymore.

The rule of "after exception it's valid to close the connection with PQfinish()
or continue processing with PQgetResult()/PQisBusy()/PQconsumeInput()" seems
quite simple and clear. Perhaps only clarification whats valid on sync
connection and whats valid on async connection would be useful.

--
marko