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

On Thu, 4 June 1998, at 13:23:17, Tom Lane wrote:

> 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.

don't be sorry! that's a good thing. not sure how I missed that.

> 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.

I beleive I will. I thought about this last night, and I came up with
this: Since what we need is secure database connections under a stable
release, I'll continue to develop my SSL patch for 6.3.2. Since I've
already done the work of "cleaning up" (I use quotes because all I've
really done is changed the functions to pass the struct ptr around,
and isolated all read/writes to two functions, pq_read & pq_write)
I'll issue two separate patches. One which modularizes the IO a
little which will make it easy for people who wish to add other layers
(like kerberos encryption) and an SSL patch to run on top of that.

I'll have to familiarize myself with the new frontend code, but I plan
on making a similar patch for 6.4 (as we'll also want SSL connections
with that). I am tempted to hold off on that once I get my current
SSL up to snuff and instead work on perl stored procedures, as I feel
that is more valuable (and will also do more to familiarize myself
with the code).

>
> > 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.)

What about OOB data? is that just data as well?

>
> > 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.

I'm sure an SSL connection can be select()'d, and it does support
non-blocking recv (I think that's the only way). I think it does
block, however, if it doesn't get a full SSL "packet" (or whatever the
appropriate term may be).

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

excellent.