Re: Speed dblink using alternate libpq tuple storage

On Tue, Mar 06, 2012 at 11:13:45AM +0900, Kyotaro HORIGUCHI wrote:
> > But it's broken in V3 protocol - getAnotherTuple() will be called
> > only if the packet is fully read.  If the packet contents do not
> > agree with packet header, it's protocol error.  Only valid EOF
> > return in V3 getAnotherTuple() is when row processor asks
> > for early exit.
> 
>  Original code of getAnotherTuple returns EOF when the bytes to
> be read is not fully loaded. I understand that this was
> inappropriately (redundant checks?) written at least for the
> pqGetInt() for the field length in getAnotherTuple.  But I don't
> understand how to secure the rows (or table data) fully loaded at
> the point of getAnotherTuple called...

Look into pqParseInput3():

	if (avail < msgLength)
	{
		...
		return;
	}


> > * remove pqIsnonblocking(conn) check when row processor returned 2.
> >   I missed that it's valid to call PQisBusy/PQconsumeInput/PQgetResult
> >   on sync connection.
> 
> mmm. EOF from getAnotherTuple makes PQgetResult try furthur
> reading until asyncStatus != PGASYNC_BUSY as far as I saw. And It
> seemed to do so when I tried to remove 'return 2'. I think that
> it is needed at least one additional state for asyncStatus to
> work EOF as desied here.

No.  It's valid to do PQisBusy() + PQconsumeInput() loop until
PQisBusy() returns 0.  Otherwise, yes, PQgetResult() will
block until final result is available.  But thats OK.

-- 
marko