Re: [HACKERS] comm patch & ssl patch

On Fri, 29 May 1998, at 03:36:52, Thomas G. Lockhart wrote:

> Anyway, it would be great if a few people would take an interest, as you
> have, in cleaning this up. The OOB discussion touches on this also, and
> if there are non-backward-compatible changes for v6.4 then you may as
> well clean up other stuff while we're at it.

the changes I propose are completely backward compatible, as far as
the network communication goes.  What other compatibility aspects
should I be worried about?

Can you fill me in on the OOB discussion?  As far as I know, we were
planning on using it for the synchronous notification, but it turns
out we can't because unix sockets won't support it.  So now we're
thinking of opening another connection to the postmaster (?) to send
the cancel message, along with some sort of authorization cookie.
We're now trying to determine the best way of making it secure, right?
I wouldn't be too worried about it, really.  Postgres can't really
protect itself against packet sniffing.  If someone can connect to
your database and delete all your tables, why are we worried about
being able to send a cancel message?

Hass this list been especially quiet lately?  Or am I not up-to-date
on the new list scheme?

> For something as fundamental as client/server communication we should
> probably have a few people testing your patches before applying things
> to the source tree; I'd be happy to help (but can only test on a
> little-endian machine) and Tatsuo in Japan has a mixed-order network
> which he has used for extensive testing in the past.

I agree wholeheartedly.  BTW, it passes the regression tests.  Not
that this means it should have the living daylights tested out of it,
but it is a promising sign.

Another question: how does each backend end up exiting?  (I'm about to
find out).  From what I can tell, when the backend receives the 'X'
character from the front-end (meaning: front-end exiting), it calls
pq_close, which closes the file pointers and sets them to null.
Then it proceeds to call NullCommand, which signals the end of a response.
But, of course, it can't do this, because its file pointers are gone.
This is inside of an infinite for(;;) loop.

I guess I'll answer my own question.  On the next iteration of the for
loop, ReadCommand is called, which in turn calls SocketBackend, which
tries to read a character.  If this fails (returns EOF) it decides to
exit.  It would seem more appropriate to exit after pq_close is called
(but not in pq_close).

comments?