Thread: comm patch & ssl patch
I've decided to make two separate patches, a "communication" patch to clean up the fe-be communication (to be submitted for inclusion) and then a separate SSL patch. this is good because, if approved for merging, will clear up a lot of inconsistency regarding the io communication in the backend and frontend. it also has the added benefit of making my SSL patch less hack-ish. I haven't heard much from you guys regarding the backend communication, but I figure if I make a good patch that doesn't interfere and has positive changes, what have we got to lose. I'm considering going as far as making it more even more modular so that it is easier for other people to take advantage of that, but I'm not sure how anyone feels about that. First things first I guess. btw, i'm still planning on implementing stored procedures in perl. i'd like to gauge the relative interest of these two projects so I can decide how to spend my time.
> I haven't heard much from you guys regarding the backend
> communication, but I figure if I make a good patch that doesn't
> interfere and has positive changes, what have we got to lose.
My impression is that the frontend/backend comm has been less-than-ideal
for some time. Someone submitted patches to fix the reversed network
byte ordering (Postgres sends little-endian using home-grown versions of
the big-endian ntoh/hton routines) but got discouraged when they didn't
quite work right on mixed-order networks.
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.
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.
- Tom
On Thu, 28 May 1998, Brett McCormick wrote: > I'm considering going as far as making it more even more modular so > that it is easier for other people to take advantage of that, but I'm > not sure how anyone feels about that. First things first I guess. You have my blessing. (For as much as it counts for anything.) :) /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */
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?
> > 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)
At 3:36 AM 98.5.29 +0000, Thomas G. Lockhart wrote: >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'm more than happy to join mixed-byte-order testing. Please let me know if you need help. -- Tatsuo Ishii t-ishii@sra.co.jp -- Tatsuo Ishii t-ishii@sra.co.jp