On Tue, Mar 14, 2017 at 4:19 AM, Daniel Verite <dan...@manitou-mail.org> wrote:
>
> I mean the next iteration of the above while statement. Referring
> to the doc, that would be the "next batch entry":
>
> " To get the result of the first batch entry the client must call
> PQbatchQueueProcess. It must then call PQgetResult and handle the
> results until PQgetResult returns null (or would return null if
> called). The result from the next batch entry may then be retrieved
> using PQbatchQueueProcess and the cycle repeated"
>
> Attached is a bare-bones testcase showing the problem.
> As it is, it works, retrieving results for three "SELECT 1"
> in the same batch. Now in order to use the single-row
> fetch mode, consider adding this:
>
> r = PQsetSingleRowMode(conn);
> if (r!=1) {
> fprintf(stderr, "PQsetSingleRowMode() failed for i=%d\n", i);
> }
>
> When inserted after the call to PQbatchQueueProcess,
> which is what I understand you're saying works for you,
> it fails for me when starting to get the results of the 2nd query
> and after.
>
>
Thanks for explaining the issue in detail and yes, I do see the issue using
your attached test file.
And I think the problem is with the "parseInput" call at the end of
PQbatchQueueProcess().
I don't see the need for "parseInput" to cover the scope of
PQbatchQueueProcess(), also anyways we do it in PQgetResult().
This function call changes the asyncstatus of connection to READY(following
command complete message from backend), so eventually PQsetSingleRowMode()
is failing. So, attached the alternative fix for this issue.
Please share me your thoughts.
I would also like to hear Craig's opinion on it before applying this fix to
the original patch, just to make sure am not missing anything here.
Thanks & Regards,
Vaishnavi,
Fujitsu Australia.
0002-single-row-mode-fix.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
