Thread: Reduce DEBUG level of catcache refreshing messages
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.
Attachment
On Fri, May 30, 2025 at 9:33 AM Jelte Fennema-Nio <postgres@jeltef.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
"Jelte Fennema-Nio" <postgres@jeltef.nl> writes:
> 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.
I don't have an opinion about the merits of this exact change, but
I wish somebody would go through all our DEBUGn messages and come up
with some coherent proposal for what the various levels should be
used for. Right now I think those choices are purely idiosyncratic
and have been made differently in different patches.
Your usage example already suggests one possible rule:
* DEBUG1 is reserved for testing patches and should never be used
in permanent code.
Maybe that particular idea is not appropriate for some reason.
But if we could have *some* kind of explainable basis for
assigning DEBUGn levels, I think our lives would be better.
regards, tom lane