Re: log_postmaster_stats

On Mon, Jul 27, 2026 at 2:47 AM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
> Now the GUC/concept is called log_excess_connection_attempts, however it is
> based on postmaster's CPU time or delay in getting CPU scheduled at all.
> I think name is nice, but one can argue it should be
> log_excess_postmaster_cpu_time too technically, but I find it way too long.

I think this is a good direction, but over the years I've acquired a
healthy skepticism of features where the documentation and the actual
behavior of the code drift apart like this. Since the feature name is
log_excess_connection_attempts, a user will tend to think that what
triggers the message is when there are a lot of connection attempts,
but it's actually trigger by high CPU usage or too much time passing
between consecutive points at which we consider logging the message.
What I think is bound to happen is that some users will not get a
message when one is expected (e.g. the number of connections is very
high but the computer handles it efficiently and so CPU usage remains
low) and others will get one when it's not expected (e.g. the
postmaster is slow because it get stuck reading or writing from the
disk or network, not because of a high connection rate).

Plus, checking the CPU usage like this is somewhat expensive, and I
doubt that high CPU usage over a 1 second period is even meaningful.

I suspect the right thing to do here is drop all the CPU usage stuff
and just make it a test for whether the connection rate is high. Then
you could also make the value of the parameter an integer, like:
log_excessive_connection_rate=100 to log whenever there are >=100
connection in 1 second. That gives the parameter a very specific
charter that is easy to guess even from just looking at the name. A
side benefit of this is that you could write a test that would pass
reliably; just set log_excessive_connection_rate=1 and try to connect.
1 >= 1 so a message should appear.

--
Robert Haas
EDB: http://www.enterprisedb.com