Re: Reducing the log spam
От | Laurenz Albe |
---|---|
Тема | Re: Reducing the log spam |
Дата | |
Msg-id | 61b835f49966b7f5853cf89de96fdc5f51f03a18.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Reducing the log spam (Isaac Morland <isaac.morland@gmail.com>) |
Ответы |
Re: Reducing the log spam
|
Список | pgsql-hackers |
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. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: