Re: [HACKERS] Upgrading postmaster's log messages about bind/listenerrors

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: [HACKERS] Upgrading postmaster's log messages about bind/listenerrors
Дата
Msg-id e3a1715d-dd25-d9bb-4a28-6839c242a2f7@joeconway.com
обсуждение исходный текст
Ответ на [HACKERS] Upgrading postmaster's log messages about bind/listen errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 03/09/2017 12:27 PM, Tom Lane wrote:
> Over in
> https://www.postgresql.org/message-id/flat/201703072317.01345.john.iliffe%40iliffe.ca
> we spent quite a lot of effort to diagnose what turned out to be a simple
> networking misconfiguration.  It would probably have taken a lot less
> effort if the postmaster were more forthcoming about exactly what address
> it's trying to bind to.  I seem to recall having wanted to include that
> info in the messages many years ago, but at the time we lacked any
> reasonably-portable way to decode a struct addrinfo.  Now we have
> pg_getnameinfo_all(), so PFA a patch to include the specific address in
> any complaint about failures in the socket/bind/listen sequence.
>
> For good measure I also added a DEBUG1 log message reporting successful
> binding to a port.  I'm not sure if there's an argument for putting this
> out at LOG level (i.e. by default) --- any thoughts about that?

+1 for making it LOG instead of DEBUG1

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] on_dsm_detach() callback and parallel tuplesort BufFile resource management