Re: Async PQgetResult() question.
От | Tom Lane |
---|---|
Тема | Re: Async PQgetResult() question. |
Дата | |
Msg-id | 325.994535202@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Async PQgetResult() question. (Matthew Hagerty <mhagerty@voyager.net>) |
Ответы |
Re: Async PQgetResult() question.
Re: Async PQgetResult() question. |
Список | pgsql-hackers |
Matthew Hagerty <mhagerty@voyager.net> writes: > If I don't call PQsetnonblocking() will that affect any of the async > functions I'm dealing with? PQsetnonblocking has nothing to do with the PQconsumeInput/PQisBusy/PQgetResult family of functions. The point of the latter is to avoid blocking while waiting for input from the database. The point of PQsetnonblocking is to avoid blocking while sending stuff to the database. Now in a TCP environment, the only way send() is going to block is if you send more stuff than there's currently room for in your kernel's networking buffers --- which typically are going to be hundreds of K. I could see needing PQsetnonblocking if you need to avoid blocking while transmitting COPY IN data to the database ... but for queries it's harder to credit. Also, unless you are sending more than one query in a query string, the backend is going to be absorbing the data as fast as it can anyway; so even if you do block it's only going to be for a network transit delay, not for database processing. Personally I've done quite a bit of asynchronous-application coding with PQconsumeInput &friends, but never felt the need for PQsetnonblocking. This is why I've not been motivated to try to fix its problems... regards, tom lane
В списке pgsql-hackers по дате отправления: