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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brett McCormick <brett(at)work(dot)chicken(dot)org>
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] some more rambling on the new fe/be communication
Date: 1998-06-04 17:23:17
Message-ID: 26013.896980997@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Brett McCormick <brett(at)work(dot)chicken(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew N. Dodd 1998-06-04 17:28:33 Neat tool? (Datasplash)
Previous Message The Hermit Hacker 1998-06-04 17:21:20 Re: [HACKERS] NEW POSTGRESQL LOGOS