Re: non-blocking connections in libpq, fix proposal

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Bernhard Herzog <bh@intevation.de> writes:
> Right.  The real problem with the design is that the return codes of a
> lot of routines aren't adequate to distinguish these cases.  However,
> I'm dubious that pqFlush is the only place where there's a problem;
> AFAIR the problem propagates out to quite a lot of places.

pqFlush is called in a lot of places, that's true. However, it seems to
me that in many of those places, it doesn't have to be called at all.

For one, for a blocking connection, pqFlush only needs to be called
after data has been put into the output buffer and most public functions
(and many internal functions) already do that before they return
(notable exceptions: PQputline and PQputnbytes). Calling pqFlush at the
beginning of a function shouldn't be necessary.

For a non-blocking connection, the program using the library can be
expected to call PQsendSome until all pending data has been sent, I
think, so it wouldn't be necessary to call pqFlush/pqSendSome at the
beginning of e.g. PQsendQuery. PQsendQuery should perhaps check whether
the buffer is empty instead.

> I think that was the same approach I had in mind awhile back --- if
> pqPutBytes only fails when it can neither send nor queue data, then
> that reduces the number of places that need to cope with "can't send
> yet" conditions.

Exactly. that's why I did it that way. I tried to make as few changes as
possible.

> > I've also added a new API function PQflushSome which analogously to
> > PQflush just calls pqFlushSome. Programs using PQsendQuery should use
> > this new function.
> 
> You mean "programs using nonblocking send should use this function", no?

Yes.

> I don't like the name "pqFlushSome" --- to me "flush" means "get rid of
> all the data or else".  Maybe "pqSendSome"?  Any other ideas out there?

I'll call it pqSendSome for now.

> Patches should go to pgsql-patches, especially if they're more than
> a few lines long.

I've sent it there. 

Regards,
  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                               http://mapit.de/