On Wed, Feb 15, 2017 at 1:31 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas <robertmh...@gmail.com> wrote: >> I think the patch as presented probably isn't quite what we want, >> because it waits synchronously for the second result to be ready. >> Note that the wait for the first result is asynchronous: we check >> PQisBusy and return without progressing the state machine until the >> latter returns false; only then do we call PQgetResult(). > > OK, I have been poking at this problem. I think that we need to > introduce a new state in ConnStatusType telling "please consume all > results until PQgetResult returns NULL" which is CONNECTION_CONSUME in > the patch attached. And as long as all the results are not consumed, > the loop just keeps going. If more messages are being waited for with > PGisBusy returning true, then the loop requests for more data to read > by switching back to PGRES_POLLING_READING. > > By the way, I am noticing as well that libpq.sgml is missing a > reference to CONNECTION_CHECK_WRITABLE. This should be present as > applications calling PQconnectPoll() could face such a status. I have > fixed this issue as well in the patch attached.
Great, thanks! This looks good to me, so committed. Is there any chance you can use your amazing TAP-test-creation powers to do some automated testing of this feature? For example, maybe we could at least set up a master and a standby and somehow test that asking for a read-only server picks the standby if it's first but asking for a read-write server tries the standby and then switches to the master? It would also be nice to test that probing a server that doesn't exist fails, but I'm not sure how to create an IP/port combination that's guaranteed to not work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
