On Wed, 2024-03-06 at 17:09 +0300, Aleksander Alekseev wrote:
> I like the idea of suppressing certain log messages in general, but
> the particular user interface doesn't strike me as an especially
> convenient one.
>
> Firstly I don't think many people remember sqlstates and what 3F000
> stands for. IMO most users don't know such a thing exists. Secondly,
> whether we should list sqlstates to suppress or the opposite - list
> the states that shouldn't be suppressed, is a debatable question. Last
> but not least, it's not quite clear whether PostgreSQL core is the
> right place for implementing this functionality. For instance, one
> could argue that the log message should just contain sqlstate and be
> directed to |grep instead.
>
> I suspect this could be one of "there is no one size fits all"
> situations. The typical solution in such cases is to form a structure
> containing the log message and its attributes and submit this
> structure to a registered hook of a pluggable logging subsystem. This
> would be the most flexible approach. It will allow not only filtering
> the messages but also using binary logging, JSON logging, logging to
> external systems like Loki instead of a given text file, etc.
>
> I don't think we currently have this in the core, but maybe I just missed it.
The target would not primarily be installations where people configure
nifty logging software to filter logs (those people know how to deal
with log spam), but installations where people don't even know enough
to configure "shared_buffers". So I'd like something that is part of
core and reduces spam without the user needing to configure anything.
I am somewhat worried that people will come up with all kinds of
justified but complicated wishes for such a feature:
- an option to choose whether to include or to exclude certain errors
- be able to configure that certain errors be logged on FATAL, but
not on ERROR
- allow exception names in addition to SQL states
- have wildcards for exception names
- ...
I would like to write a simple patch that covers the basic functionality
I described, provided enough people find it useful. That does not
exclude the option for future extensions for this feature.
Yours,
Laurenz Albe