Re: Invalid length of startup packet
От | Nigel J. Andrews |
---|---|
Тема | Re: Invalid length of startup packet |
Дата | |
Msg-id | Pine.LNX.4.21.0205281517460.2351-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Re: Invalid length of startup packet (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Invalid length of startup packet
|
Список | pgsql-general |
On Tue, 28 May 2002, Tom Lane wrote: > Ron Snyder <snyder@roguewave.com> writes: > > If we portscan our database server and include the postgres port in the list > > of scanned ports, we'll get that error in our logs. You can also get that > > message by attempting to telnet to your postgres port. I'm a little > > surprised that postgres doesn't list some source ip information with the > > message. > > It would be fairly easy to rearrange the code in postmaster.c so that > a log message like "attempted connection from host xxx port yyy" is > emitted before we try to receive and interpret the startup packet. > But I don't think we can guarantee that every error condition that might > occur in that stretch of code could be modified to include host/port in > the text of the error message. So the "attempted connection" message > would have to be logged unconditionally for every connection attempt. > Does that seem useful? Would you want it to be automatic when > LOG_CONNECTIONS is on, or should it require some higher-than-normal > debug setting? I just looked at the ProcessStartupPacket code to see about doing a patch. I noticed a few elog()s and thought that supplying the remote connection information to cover all of these would be a bit of a hassle. Then I wondered if it was necessary since I presumed all connections could be logged, if a fatal error occurs the connection won't be listed by netstat by the time someone looks, so all that's needed is that the connection log records the information. Obviously, that's not entirely usable if connections are being made and dropped by applications. So how about elog() sticking the backend slot number into all messages? Is that sort of information available in elog? (I'm just looking at that now but can't say after only a quick scan and with my small knowledge of the backend code) -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
В списке pgsql-general по дате отправления: