>
> 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)