Thread: New message in PostgreSQL log regarding socket for statistics collector
I'm working on an implementation of PostgreSQL 13.8 on a Linux RHEL8 sandbox environment.
Thanks, Karin
The server & PostgreSQL have all been configured.
I started PostgreSQL & got the following messages in the log file:
2022-09-16 02:00:16 EDT [1918984]: [3-1] db=,user= LOG: starting PostgreSQL 13.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-10), 64-bit
2022-09-16 02:00:16 EDT [1918984]: [4-1] db=,user= LOG: listening on IPv4 address "0.0.0.0", port 5432
2022-09-16 02:00:16 EDT [1918984]: [5-1] db=,user= LOG: listening on IPv6 address "::", port 5432
2022-09-16 02:00:16 EDT [1918984]: [6-1] db=,user= LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
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
2022-09-16 02:00:17 EDT [1918986]: [1-1] db=,user= LOG: database system was shut down at 2022-09-14 17:26:53 EDT
2022-09-16 02:00:17 EDT [1918984]: [10-1] db=,user= LOG: database system is ready to accept connections
I'm concerned about the "test message did not get through on socket for statistics collector" & "trying another address for the statistics collector" messages.
I've never seen these before & wasn't able to find anything about them via a Google search. What I did find, talked about the unix socket directories. I left that parameter at the default setting:
#unix_socket_directories = '/var/run/postgresql, /tmp' # comma-separated list of directories
I checked both of those locations & found the following entries:
[postgres@xxxxxx ~]$ ls -al /var/run/postgresql/
total 4
drwxr-xr-x 2 postgres postgres 80 Sep 16 02:00 .
drwxr-xr-x 30 root root 900 Aug 31 13:17 ..
srwxrwxrwx 1 postgres postgres 0 Sep 16 02:00 .s.PGSQL.5432
-rw------- 1 postgres postgres 67 Sep 16 02:00 .s.PGSQL.5432.lock
[postgres@xxxxxx ~]$ cat /var/run/postgresql/.s.PGSQL.5432.lock
1918984
/var/lib/pgsql/13/data
1663308016
5432
/var/run/postgresql
[postgres@xxxxxx ~]$ ls -al /tmp/ | grep .s.PGSQL
srwxrwxrwx 1 postgres postgres 0 Sep 16 02:00 .s.PGSQL.5432
-rw------- 1 postgres postgres 52 Sep 16 02:00 .s.PGSQL.5432.lock
[postgres@xxxxxx ~]$ cat /tmp/.s.PGSQL.5432.lock
1918984
/var/lib/pgsql/13/data
1663308016
5432
/tmp
Is there anything that I should be concerned about regarding these messages or are they normal?
Also, should I change the unix_socket_directories parm to just have one directory? In past versions of PostgreSQL, we've just had one directory:
#unix_socket_directories = '/tmp'
Karin Hilbert
Database Administration
Pennsylvania State University
Re: New message in PostgreSQL log regarding socket for statistics collector
From
Christoph Moench-Tegeder
Date:
## 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
Re: New message in PostgreSQL log regarding socket for statistics collector
From
"Hilbert, Karin"
Date:
Christoph,
Thank you for your explanation.
That puts my mind at ease.
Regards, Karin
From: Christoph Moench-Tegeder <cmt@burggraben.net>
Sent: Friday, September 16, 2022 3:43 PM
To: Hilbert, Karin <ioh1@psu.edu>
Cc: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: New message in PostgreSQL log regarding socket for statistics collector
Sent: Friday, September 16, 2022 3:43 PM
To: Hilbert, Karin <ioh1@psu.edu>
Cc: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: New message in PostgreSQL log regarding socket for statistics collector
## 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
> 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