Re: New message in PostgreSQL log regarding socket for statistics collector

Поиск
Список
Период
Сортировка
От Christoph Moench-Tegeder
Тема Re: New message in PostgreSQL log regarding socket for statistics collector
Дата
Msg-id YyTR1b/yZ3MqBHq+@elch.exwg.net
обсуждение исходный текст
Ответ на New message in PostgreSQL log regarding socket for statistics collector  ("Hilbert, Karin" <ioh1@psu.edu>)
Ответы Re: New message in PostgreSQL log regarding socket for statistics collector  ("Hilbert, Karin" <ioh1@psu.edu>)
Список pgsql-general
## Hilbert, Karin (ioh1@psu.edu):

> 2022-09-16 02:00:16 EDT [1918984]: [7-1] db=,user= LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
> 2022-09-16 02:00:17 EDT [1918984]: [8-1] db=,user= LOG:  test message did not get through on socket for statistics
collector
> 2022-09-16 02:00:17 EDT [1918984]: [9-1] db=,user= LOG:  trying another address for the statistics collector

> I'm concerned about the "test message did not get through on socket
> for statistics collector" & "trying another address for the statistics
> collector" messages.

That's the stats collector socket, which is used to communicate runtime
statistic updates inside the server. As a user, you'll never interact
with this socket directly. It's created on the first working address
which the system returns as "localhost". The server will try all the
"localhost" addresses until the socket can be created and passes the
test message, logging messages similar to your message for each failure.
In your case the test message was not received (or it was received
too late - the server waits only 0.5 seconds for the test message).
In any case, a working stats socket was created on your machine:
without a working stats socket server startup will fail. (You should
be able to see that socket in each PostgreSQL process' file descriptors:
UDP, localhost, high port, "connected" to the very same address/port
tuple).
Why did the test message fail on your first socket? Maybe there's
some filtering in place, or your system was very slow and missed
the 500ms timeout, or the address was otherwise unusable (not
available in that namespace, trying to use IPv4/IPv6 when not
configured... I'd have to test which condition results in failure
at this stage).

Regards,
Christoph

-- 
Spare Space



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

Предыдущее
От: "Kluzak, Matthew C."
Дата:
Сообщение: RE: Bind Parameter is Too Big
Следующее
От: "Hilbert, Karin"
Дата:
Сообщение: Re: New message in PostgreSQL log regarding socket for statistics collector