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?

Yes, you are correct.
> 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).

Any cleanup you can do would be helpful.  Sounds like you are on-top of
it.


--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)