From: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
---|---|
To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reduce DEBUG level of catcache refreshing messages |
Date: | 2025-05-30 13:32:18 |
Message-ID: | CAFcNs+owQqemL3ttZ0tDLitpFQmSu+g6G8dWVUsfQNp0BW=_jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 30, 2025 at 9:33 AM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
wrote:
> When testing extensions using pgregress, it can be useful to introduce
> some new DEBUG logs which are specific to the extension and change the
> log level during part of the of the test.
>
> There's a problem though: Often a "rehashing catalog cache ..." debug
> message will also show up in those cases. It's not always possible to
> predict when these messages show, and when they do their contents can
> easily change if changes are made to an unrelated test or when run
> against a different Postgres version. This change lowers the log level
> of these messages to DEBUG5, so that they can be ignored while still
> showing other (more predictable) DEBUG messages.
>
This is a very good idea. In TimescaleDB we filter out such kind of output
in order to not end up with flaky test outputs.
The patch LGTM.
--
Fabrízio de Royes Mello
From | Date | Subject | |
---|---|---|---|
Next Message | Zhou, Zhiguo | 2025-05-30 13:38:27 | Re: Optimize shared LWLock acquisition for high-core-count systems |
Previous Message | Andrey Borodin | 2025-05-30 12:55:44 | Re: Persist injection points across server restarts |