Please add this to the next commitfest, so that we don't forget it.
On Wed, Feb 1, 2017 at 3:58 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> On Tue, Jan 31, 2017 at 9:53 AM, Higuchi, Daisuke
> <higuchi.daisuke@jp.fujitsu.com> wrote:
>> Hello,
>>
>> This this is my first posting to the mailing list.
>>
>> I am interested in multiple hosts of libpq [1], then I found the bug in this feature.
>> When I set "target_session_attrs" to "any" and call PQsendQuery, my application is succeeded.
>> However, when I set "target_session_attrs" to "read-write" and call PQsendQuery, "another command is already in
progress"is occurred.
>> I attached the test application to reproduce this problem.
>>
>> I think this is because PQgetResult is not called until PQgetResult has returned a null pointer.
>> So, I attached the patch for fix this.
>>
>> [1]
https://www.postgresql.org/message-id/flat/20150818041850.GA5092@wagner.pp.ru#20150818041850.GA5092@wagner.pp.ru
>>
> Interestingly, when I don't set PGPORT, PGHOST I get the same error
> with the C program. The patch fixes the problem.
>
> Per the documentation [1], "PQgetResult must be called repeatedly
> until it returns a null pointer, indicating that the command is
> done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE
> case, violates that. The patch fixes it. The patch however jumps to
> keep_going without changing conn->status, which means that it will end
> up again in the same case. While that's fine, may be we should use a
> local loop on PQgetResult() to keep the code readable.
>
> I would have added a test with the patch, but it seems we don't have
> much tests in interfaces/libpq. The bug is pretty trivial and would
> have been caught easily had we had any tests.
>
> [1] https://www.postgresql.org/docs/devel/static/libpq-async.html
>
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company