Re: Reducing the log spam

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Reducing the log spam
Date: 2024-06-17 21:40:01
Message-ID: ZnCtMXmqO0IZ6j9r@pryzbyj2023
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 02, 2024 at 12:47:45PM +0200, Laurenz Albe wrote:
> On Mon, 2024-03-11 at 09:33 +0100, Jelte Fennema-Nio wrote:
> > -   the subscriber's server log.
> > +   the subscriber's server log if you remove <literal>23505</literal> from
> > +   <xref linkend="guc-log-suppress-errcodes"/>.
> >
> > This seems like a pretty big regression. Being able to know why your
> > replication got closed seems pretty critical.
>
> Yes. But I'd argue that that is a shortcoming of logical replication:
> there should be a ways to get this information via SQL. Having to look into
> the log file is not a very useful option.
>
> The feature will become much less useful if unique voilations keep getting logged.

Uh, to be clear, your patch is changing the *defaults*, which I found
surprising, even after reaading the thread. Evidently, the current
behavior is not what you want, and you want to change it, but I'm *sure*
that whatever default you want to use at your site/with your application
is going to make someone else unhappy. I surely want unique violations
to be logged, for example.

> @@ -6892,6 +6892,41 @@ local0.* /var/log/postgresql
> </listitem>
> </varlistentry>
>
> + <varlistentry id="guc-log-suppress-errcodes" xreflabel="log_suppress_errcodes">
> + <term><varname>log_suppress_errcodes</varname> (<type>string</type>)
> + <indexterm>
> + <primary><varname>log_suppress_errcodes</varname> configuration parameter</primary>
> + </indexterm>
> + </term>
> + <listitem>
> + <para>
> + Causes <literal>ERROR</literal> and <literal>FATAL</literal> messages
> + from client backend processes with certain error codes to be excluded
> + from the log.
> + The value is a comma-separated list of five-character error codes as
> + listed in <xref linkend="errcodes-appendix"/>. An error code that
> + represents a class of errors (ends with three zeros) suppresses logging
> + of all error codes within that class. For example, the entry
> + <literal>08000</literal> (<literal>connection_exception</literal>)
> + would suppress an error with code <literal>08P01</literal>
> + (<literal>protocol_violation</literal>). The default setting is
> + <literal>23505,3D000,3F000,42601,42704,42883,42P01,57P03</literal>.
> + Only superusers and users with the appropriate <literal>SET</literal>
> + privilege can change this setting.
> + </para>

> +
> + <para>
> + This setting is useful to exclude error messages from the log that are
> + frequent but irrelevant.

I think you should phrase the feature as ".. *allow* skipping error
logging for messages ... that are frequent but irrelevant for a given
site/role/DB/etc."

I suggest that this patch should not change the default behavior at all:
its default should be empty. That you, personally, would plan to
exclude this or that error code is pretty uninteresting. I think the
idea of changing the default behavior will kill the patch, and even if
you want to propose to do that, it should be a separate discussion.
Maybe you should make it an 002 patch.

> + {"log_suppress_errcodes", PGC_SUSET, LOGGING_WHEN,
> + gettext_noop("ERROR and FATAL messages with these error codes don't get logged."),
> + NULL,
> + GUC_LIST_INPUT
> + },
> + &log_suppress_errcodes,
> + DEFAULT_LOG_SUPPRESS_ERRCODES,
> + check_log_suppress_errcodes, assign_log_suppress_errcodes, NULL

> +/*
> + * Default value for log_suppress_errcodes. ERROR or FATAL messages with
> + * these error codes are never logged. Error classes (error codes ending with
> + * three zeros) match all error codes in the class. The idea is to suppress
> + * messages that usually don't indicate a serious problem but tend to pollute
> + * the log file.
> + */
> +
> +#define DEFAULT_LOG_SUPPRESS_ERRCODES "23505,3D000,3F000,42601,42704,42883,42P01,57P03"
> +

../src/backend/utils/errcodes.txt:23505 E ERRCODE_UNIQUE_VIOLATION unique_violation
../src/backend/utils/errcodes.txt:3D000 E ERRCODE_INVALID_CATALOG_NAME invalid_catalog_name
../src/backend/utils/errcodes.txt:3F000 E ERRCODE_INVALID_SCHEMA_NAME invalid_schema_name
../src/backend/utils/errcodes.txt:42601 E ERRCODE_SYNTAX_ERROR syntax_error
../src/backend/utils/errcodes.txt:3D000 E ERRCODE_UNDEFINED_DATABASE
../src/backend/utils/errcodes.txt:42883 E ERRCODE_UNDEFINED_FUNCTION undefined_function
../src/backend/utils/errcodes.txt:3F000 E ERRCODE_UNDEFINED_SCHEMA
../src/backend/utils/errcodes.txt:42P01 E ERRCODE_UNDEFINED_TABLE undefined_table
../src/backend/utils/errcodes.txt:42704 E ERRCODE_UNDEFINED_OBJECT undefined_object
../src/backend/utils/errcodes.txt:57P03 E ERRCODE_CANNOT_CONNECT_NOW cannot_connect_now

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-06-17 21:43:05 Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
Previous Message Andres Freund 2024-06-17 21:37:19 Re: cost delay brainstorming