Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoph,
Thank you for your explanation.
That puts my mind at ease.
Regards, Karin

From: Christoph Moench-Tegeder <cmt@xxxxxxxxxxxxxx>
Sent: Friday, September 16, 2022 3:43 PM
To: Hilbert, Karin <ioh1@xxxxxxx>
Cc: pgsql-general@xxxxxxxxxxxxxxxxxxxx <pgsql-general@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: New message in PostgreSQL log regarding socket for statistics collector
 
## Hilbert, Karin (ioh1@xxxxxxx):

> 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux