By digoal
For each client connection request to Postmaster in PostgreSQL (listened to on port 5432 by default), a backend process would be created. It then processes the startup packet from the client. Refer to src/backend/postmaster/postmaster.c
for the source code.
Each client connection request is expected to send a startup message to the PostgreSQL server, and the information in the startup packet is used for setting up the backend process. But there are many more things happening when we deploy PostgreSQL in a data center. There could be different monitoring solutions, security scanners, port scanners, and HA solutions, among others hitting on PostgreSQL Port 5432.
PostgreSQL starts processing these incoming connections for establishing a client-server communication channel. But these tools can have different intentions and may not participate in a good client-server protocol.
Historically, PostgreSQL generates a log entry for each of these suspected or bad hits. This can result in log files becoming huge and unwanted log-related IO.
After receiving a connection request from the client, wait for the client startup package. However, different clients have different purposes (some clients only check whether the remote database ports are connected) and will not send the startup packet to the database. In this case, the database would print the incomplete startup packet error logs in versions earlier than PG12.
PostgreSQL 12, however, no longer prints logs generated from monitoring and checking whether the database is alive (incomplete startup packet).
This will stop logging cases where, for example, a monitor opens a connection and immediately closes it. If the packet contains any data, an incomplete packet will still be logged.
for i in {1..100}; do
nc -zv localhost 5432 ;
done
For versions earlier than PG12, the logs printed are as follows:
2019-11-28 13:24:26.501 UTC [15168] LOG: incomplete startup packet
2019-11-28 13:24:26.517 UTC [15170] LOG: incomplete startup packet
2019-11-28 13:24:26.532 UTC [15172] LOG: incomplete startup packet
2019-11-28 13:24:26.548 UTC [15174] LOG: incomplete startup packet
2019-11-28 13:24:26.564 UTC [15176] LOG: incomplete startup packet
2019-11-28 13:24:26.580 UTC [15178] LOG: incomplete startup packet
2019-11-28 13:24:26.595 UTC [15180] LOG: incomplete startup packet
2019-11-28 13:24:26.611 UTC [15182] LOG: incomplete startup packet
2019-11-28 13:24:26.627 UTC [15184] LOG: incomplete startup packet
2019-11-28 13:24:26.645 UTC [15186] LOG: incomplete startup packet
2019-11-28 13:24:26.666 UTC [15188] LOG: incomplete startup packet
2019-11-28 13:24:26.687 UTC [15190] LOG: incomplete startup packet
2019-11-28 13:24:26.710 UTC [15192] LOG: incomplete startup packet
2019-11-28 13:24:26.729 UTC [15194] LOG: incomplete startup packet
2019-11-28 13:24:26.748 UTC [15196] LOG: incomplete startup packet
...
PG12 no longer prints these logs. Note that if the client does not send a zero size package, PG12 still records the logs as follows:
2019-11-28 14:27:49.728 UTC [17982] LOG: invalid length of startup packet
2019-11-28 14:28:14.907 UTC [17983] LOG: invalid length of startup packet
2019-11-28 14:28:18.236 UTC [17984] LOG: invalid length of startup packet
Explanation from Tom Lane:
"The agreed-to behavior change was not to log anything if the connection is closed without any data having been sent. If the client does send something, and it doesn't look like a valid connection request, I think we absolutely should log that."
If the following logs are received, it indicates that the client did not close the connection normally.
Such entries are also not going away. This happens when the server process tries to read packets (Refer to the pq_recvbuf function in src/backend/libpq/pqcomm.c
) sent from its client-side and then realizes that the client-side is already lost, which means that the client ended communication without a good handshake.
2019-11-28 14:11:45.273 UTC [17951] LOG: could not receive data from client: Connection reset by peer
2019-11-28 14:11:47.328 UTC [17953] LOG: could not receive data from client: Connection reset by peer
2019-11-28 14:11:48.425 UTC [17955] LOG: could not receive data from client: Connection reset by peer
2019-11-28 14:27:11.870 UTC [17978] LOG: could not receive data from client: Connection reset by peer
For versions earlier than PG12, the incomplete startup packet is also printed if the preceding issues are reported:
2019-11-28 13:53:31.721 UTC [15446] LOG: could not receive data from client: Connection reset by peer
2019-11-28 13:53:31.721 UTC [15446] LOG: incomplete startup packet
2019-11-28 13:54:04.014 UTC [15450] LOG: could not receive data from client: Connection reset by peer
2019-11-28 13:54:04.014 UTC [15450] LOG: incomplete startup packet
2019-11-28 14:01:55.514 UTC [15479] LOG: could not receive data from client: Connection reset by peer
2019-11-28 14:01:55.514 UTC [15479] LOG: incomplete startup packet
postgres@pg11-test-> pg_isready --help
pg_isready issues a connection check to a PostgreSQL database.
Usage:
pg_isready [OPTION]...
Options:
-d, --dbname=DBNAME database name
-q, --quiet run quietly
-V, --version output version information, then exit
-?, --help show this help, then exit
Connection options:
-h, --host=HOSTNAME database server host or socket directory
-p, --port=PORT database server port
-t, --timeout=SECS seconds to wait when attempting connection, 0 disables (default: 3)
-U, --username=USERNAME user name to connect as
Report bugs to <pgsql-bugs@postgresql.org>.
PostgreSQL v12 Performance: Alibaba Cloud ECS Local SSD vs. ESSD PL3
Alibaba Clouder - June 13, 2019
OpenAnolis - August 9, 2022
Alibaba Cloud Native - August 14, 2024
Alibaba Cloud Native - March 5, 2024
block - September 14, 2021
digoal - August 3, 2021
Alibaba Cloud PolarDB for PostgreSQL is an in-house relational database service 100% compatible with PostgreSQL and highly compatible with the Oracle syntax.
Learn MoreAn online MPP warehousing service based on the Greenplum Database open source program
Learn MoreTair is a Redis-compatible in-memory database service that provides a variety of data structures and enterprise-level capabilities.
Learn MoreAn all-in-one service for log-type data
Learn MoreMore Posts by digoal