Re: FE/BE protocol oddity
От | Peter Eisentraut |
---|---|
Тема | Re: FE/BE protocol oddity |
Дата | |
Msg-id | Pine.LNX.4.30.0107061802520.679-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: FE/BE protocol oddity (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: FE/BE protocol oddity
|
Список | pgsql-hackers |
Tom Lane writes: > Good point. Probably, PQfinish should only send the X message if the > connection has gotten past the authentication stage. A separate but > also useful change would be to do immediate socket close on detecting > auth failure, before returning to the client application. Further investigation shows that all of this used to work correctly until the infamous async connection patch. The comment now reads: (fe-connect.c) /* * We used to close the socket at this point, but that makes it * awkward for those above us if they wish to remove thissocket from * their own records (an fd_set for example). We'll just have this * socket closed when PQfinish is called(which is compulsory even * after an error, since the connection structure must be freed). */ I guess there is sort of a point there. So I'm leaning towards adding a "startup complete" flag somewhere in PGconn and simply fix up closePGconn(). > > Btw., is recv(sock, x, 1, MSG_PEEK) == 0 an appropriate way to check for a > > closed connection without reading anything? > > Seems a little risky as far as portability goes; is MSG_PEEK supported > on BeOS, Darwin, Cygwin, etc? Darwin is FreeBSD, so yes. Cygwin says it supports recv() and MSG_PEEK is trivial from there. BeOS is going backrupt before the next release anyway. ;-) Seriously, in the worst case we'll get EINVAL. > Might be better to fix the backend libpq routines to understand > whether a connection-close event is expected or not, and only emit a > complaint to the log when it's not. Not sure how far such a change > would need to propagate though... Deep... -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
В списке pgsql-hackers по дате отправления: