Re: [HACKERS] [Bug fix] PQsendQuery occurs error whentarget_session_attrs is set to read-write
От | Ashutosh Bapat |
---|---|
Тема | Re: [HACKERS] [Bug fix] PQsendQuery occurs error whentarget_session_attrs is set to read-write |
Дата | |
Msg-id | CAFjFpRddYBEfUgbc1=kNvTOs_ozMj6PrHDmE7F=thRSVRYn+FA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [Bug fix] PQsendQuery occurs error whentarget_session_attrs is set to read-write (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: [HACKERS] [Bug fix] PQsendQuery occurs error whentarget_session_attrs is set to read-write
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: