From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | markokr(at)gmail(dot)com |
Cc: | greg(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, mmoncure(at)gmail(dot)com, shigeru(dot)hanada(at)gmail(dot)com |
Subject: | Re: Speed dblink using alternate libpq tuple storage |
Date: | 2012-03-07 00:43:54 |
Message-ID: | 20120307.094354.186534216.horiguchi.kyotaro@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2012-03-07 01:04:28 | Re: Speed dblink using alternate libpq tuple storage |
Previous Message | Tom Lane | 2012-03-07 00:01:46 | Re: pgsql_fdw, FDW for PostgreSQL server |