Re: [HACKERS] comm patch & ssl patch

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: brett(at)work(dot)chicken(dot)org (Brett McCormick)
Cc: lockhart(at)alumni(dot)caltech(dot)edu, pgsql-hackers(at)hub(dot)org, t-ishii(at)sra(dot)co(dot)jp
Subject: Re: [HACKERS] comm patch & ssl patch
Date: 1998-05-29 14:25:57
Message-ID: 199805291425.KAA07926@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> 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(at)candle(dot)pha(dot)pa(dot)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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-05-29 14:28:25 Lots 'o patches
Previous Message Michael Meskes 1998-05-29 13:01:00 mpsql