Horton

Re: Reducing the log spam

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Jim Jones <jim.jones@uni-muenster.de>, Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Isaac Morland <isaac.morland@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-04-02T13:11:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. plpgsql: make WHEN OTHERS distinct from WHEN SQLSTATE '00000'.


On 2025/03/17 17:12, Jim Jones wrote:
> 
> On 15.03.25 07:12, Laurenz Albe wrote:
>> ... and here is v7, improved in the spirit of
>> https://postgr.es/m/E132D362-A669-4606-AFE1-B45C9DFCC141%40yesql.se
> 
> 
> I just revisited this patch and v7 passes all tests from [1,2].
> LGTM.

Since this patch is marked as ready for committer, I've started looking at it.

Filtering log messages by SQLSTATE might be useful for some users,
but I'm unsure if it should belong in the core. There are also other
potential filtering needs, such as by application name, client host,
database, or roles. Adding only SQLSTATE filtering may not be good idea,
while supporting all possible cases in the core wouldn't be practical either.

Given that, I think implementing this as an extension using emit_log_hook
would be a better approach. Anyway, I'd like to hear more opinions from
other hackers on this.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION