Re: [HACKERS] some more rambling on the new fe/be communication

Brett McCormick <brett@work.chicken.org> writes:
> [ Brett was unpleasantly surprised to find major changes in libpq ]

Sorry about that, Brett.  This was discussed on the hackers list a month
or so ago, but evidently you missed the thread.  I made some fairly
major changes in the client-side libpq to allow it to be used
asychronously, that is without blocking until the completion of a query.

I didn't bother to do much cleanup of the backend side, since it didn't
have to change to get the functionality I was after.  I agree that it
could stand a cleanup, so if you want to do it, by all means do.

> it would appear that libpq now has a outgoing data buffer associated
> with PGconn struct which only gets sent (with send()!?) when pqFlush
> gets called.  the backend still appears to use and pass FILE * for
> reading and writing.  I wasn't aware that you can read data from a
> FILE * sent with send() over a socket.  Is this portable?

Yes.  Data on a connection is data; there's no way for the far end to
tell what syscall or library was used to collect and send the data.
(The far end might not even be Unix or C based, after all.)

> In any case, I don't think this bodes well for my SSL patch -- and I
> think I've missed something -- why have we switched to send/recv?

Because going through the stdio library gives up control over blocking
when no data is available.  getc() will block, period.

Does SSL support non-blocking recv?  If so it shouldn't be hard to put
an SSL layer under what I did with libpq.  Note the existence of
PQsocket() however.  If an SSL connection can't be select()'d for then
we have got trouble.

BTW, I believe I did fix your earlier complaint that the backend called
pq_putstr again after closing the client connection.

            regards, tom lane