Uh oops! I misread IIRC as (IRC, i.e. Internet Relay Chat or something
similar.) It is too early! ;) I'll dig in the archives.
Thanks,
Matthew
At 12:03 PM 7/8/2001 -0400, Matthew Hagerty wrote:
>At 11:44 PM 7/7/2001 -0400, Tom Lane wrote:
>>Matthew Hagerty <[EMAIL PROTECTED]> writes:
>> > So
At 11:44 PM 7/7/2001 -0400, Tom Lane wrote:
>Matthew Hagerty <[EMAIL PROTECTED]> writes:
> > So then how would I code for the exception, i.e. the backend goes down
> just
> > before or during my call to PQsendQuery()? If I am non-blocking then I
> can
> > determine that my query did not go (PQs
Matthew Hagerty <[EMAIL PROTECTED]> writes:
> So then how would I code for the exception, i.e. the backend goes down just
> before or during my call to PQsendQuery()? If I am non-blocking then I can
> determine that my query did not go (PQsendQuery() or PQflush() returns an
> error) and attemp
At 03:46 PM 7/7/2001 -0400, Tom Lane wrote:
>Matthew Hagerty <[EMAIL PROTECTED]> 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.
I said:
> 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.
Actually, forget the "unless" part --
Matthew Hagerty <[EMAIL PROTECTED]> 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 whil
At 02:13 PM 7/7/2001 -0400, Tom Lane wrote:
>Matthew Hagerty <[EMAIL PROTECTED]> writes:
> > Only applications that have used PQsetnonblocking have a need for this."
>
> > Since I use PQsetnonblocking(), I included PQflush().
>
>Hmm. My opinions about the PQsetnonblocking patch are on record:
>it
Matthew Hagerty <[EMAIL PROTECTED]> writes:
> Only applications that have used PQsetnonblocking have a need for this."
> Since I use PQsetnonblocking(), I included PQflush().
Hmm. My opinions about the PQsetnonblocking patch are on record:
it's broken and needs fundamental redesign before it ha
Thanks for the response Tom! Does anyone ever tell you how much you are
appreciated? If not, I will. When I post to pgHackers I know I will get a
response (usually) from many knowledgeable people, and for that I thank
everyone. But I *always* receive a response from Tom, and for that I am
Matthew Hagerty <[EMAIL PROTECTED]> writes:
> I'm working with pqlib in asynchronous mode and I have a question about
> PQgetResult. I have this situation:
> submit a query via PQsendQuery()
> flush to the backend with PQflush()
I think the flush is not necessary; PQsendQuery should do it.
>
Greetings,
I'm working with pqlib in asynchronous mode and I have a question about
PQgetResult. I have this situation:
submit a query via PQsendQuery()
flush to the backend with PQflush()
set my read descriptor on the socket and enter a select()
select returns read_ready on the socket, so ca
11 matches
Mail list logo