Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group