Re: Reducing the log spam

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Reducing the log spam
Date: 2024-03-09 13:03:55
Message-ID: 23a1b1c79d4a6ba0d6ec07b990d4bfe9aececd7a.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2024-03-07 at 08:30 +0100, Laurenz Albe wrote:
> On Wed, 2024-03-06 at 17:33 -0500, Isaac Morland wrote:
> > I have two questions about this:
> >
> > First, can it be done per role? If I have a particular application which is
> > constantly throwing some particular error, I might want to suppress it, but
> > not suppress the same error occasionally coming from another application.
> > I see ALTER DATABASE name SET configuration_parameter … as being useful here,
> > but often multiple applications share a database.
> >
> > Second, where can this setting be adjusted? Can any session turn off logging
> > of arbitrary sets of sqlstates resulting from its queries? It feels to me
> > like that might allow security problems to be hidden. Specifically, the first
> > thing an SQL injection might do would be to turn off logging of important
> > error states, then proceed to try various nefarious things.
>
> I was envisioning the parameter to be like other logging parameters, for
> example "log_statement": only superusers can set the parameter or GRANT
> that privilege to others. Also, a superuser could use ALTER ROLE to set
> the parameter for all sessions by that role.
>
> > It seems to me the above questions interact; an answer to the first might be
> > "ALTER ROLE role_specification SET configuration_parameter", but I think that
> > would allow roles to change their own settings, contrary to the concern
> > raised by the second question.
>
> If a superuser sets "log_statement" on a role, that role cannot undo or change
> the setting. That's just how I plan to implement the new parameter.

Here is a patch that implements this.

I went with "log_suppress_errcodes", since the term "error code" is used
throughout our documentation.

The initial value is 23505,3D000,3F000,42601,42704,42883,42P01,57P03

Yours,
Laurenz Albe

Attachment Content-Type Size
v1-0001-Add-parameter-log_suppress_errcodes.patch text/x-patch 10.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2024-03-09 13:07:40 Re: Improving EXPLAIN's display of SubPlan nodes
Previous Message Jelte Fennema-Nio 2024-03-09 12:32:38 Re: Make query cancellation keys longer