Horton

Re: Speed dblink using alternate libpq tuple storage

Kyotaro Horiguchi <horiguchi.kyotaro@oss.ntt.co.jp>

View thread
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>
To: markokr@gmail.com
Cc: greg@2ndquadrant.com, pgsql-hackers@postgresql.org, mmoncure@gmail.com, shigeru.hanada@gmail.com
Date: 2012-03-07T00:43:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix COPY FROM for null marker strings that correspond to invalid encoding.

  2. Improve labeling of pg_test_fsync open_sync test output.

Hello, 

> But I don't understand how to secure the rows (or table data)
> fully loaded at the point of getAnotherTuple called...

I found how pqParseInput ensures the entire message is loaded
before getAnotherTuple called.

fe-protocol3.c:107
|   avail = conn->inEnd - conn->inCursor;
|   if (avail < msgLength)
|   {
|     if (pqCheckInBufferSpace(conn->inCursor + (size_t)msgLength, conn))

So now I convinced that the whole row data is loaded at the point
that getAnotherTuple is called. I agree that getAnotherTuple
should not return EOF to request for unloaded part of the
message.

Please wait for a while for the new patch.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center