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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers