On Mon, Jul 27, 2026 at 2:47 AM Jakub Wartak <[email protected]> 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
