What should I do about PostgreSQL logging so much "weird noise" in its own log?

Question

PostgreSQL 12.4 on Windows 10 Pro 2004.

With the default configuration file, I start PostgreSQL with pg_ctl and the "-l PostgreSQL.txt" option.

It logs to that file. Looking in it, I'm seeing a ton of this logged:

LOG:  could not receive data from client: An existing connection was forcibly closed by the remote host.
ERROR:  deadlock detected at character 13
WARNING:  there is no transaction in progress
WARNING:  there is already a transaction in progress

Just about anything seems to be a warning: if there is a transaction in progress and if there isn't!

This one is downright absurd since I am looking at the server log... where it's telling me to look in the server log:

HINT:  See server log for query details.

It should be noted that I handle all deadlocks correctly in my application, and suppress such "errors" so that I never see them. However, they are still clearly happening and logged to PostgreSQL's own log file.

Is this normal/intended? I don't like that these errors are apparently happening "under the hood" with no affect on my applications.

Especially the "could not receive data from client" one has proven impossible to get rid of over the years; I've countless times researched it without finding any new information on that. It seems to happen regardless of what I do. I do close all database connections.

These "warnings" just profoundly bewilder me:

WARNING:  there is no transaction in progress
WARNING:  there is already a transaction in progress

I know that there are "noise levels" I can set in the configuration file, but should I set those to "silence" all of these supposed errors/problems? PG calls these "WARNINGS", "ERRORS" and "LOG". It seems like they are important even though my own error log is empty at all times from these, and I haven't noticed any kind of issue arising from them. I just don't like that they apparently happen, and it feel as if they cannot be "good".

Answer 1

All of these messages are relevant, and the fact that your application doesn't log them has no impact on that.

• LOG:  could not receive data from client:
  

  That means that your application (or a firewall in between) terminated the connection without properly closing it. That is either sloppy coding in the application or a misconfigured network.

• ERROR:  deadlock detected at character 13
  

  While correctly handled deadlocks are not detrimental, having too many of them is bad for performance and concurrency. The log contains important details that help analyzing the problem.

• WARNING:  there is [no|already a] transaction in progress
  

  Somebody ran COMMIT when there was no active transaction or START TRANSACTION inside a transaction. Both indicate that there might be something wrong with the application logic.

It is easy to get rid of the warnings with log_min_messages = error, but I personally wouldn't want to get rid of the others. It is always easy to grep -v the messages you are not interested in – oh, sorry, I forgot you were using Windows.

You can of course get rid of them all by setting the level to fatal, but then you will probably also not welcome messages about connection attempts to non-existing databases...

In short, it seems that you don't want messages from the database at all. So set log_min_messages = panic and you won't be bothered again.