Re: Reduce DEBUG level of catcache refreshing messages

On Fri, 30 May 2025 at 16:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Agreed. I'll start with a concrete proposal then:

DEBUG1 is reserved for usage by extensions and for manually testing
patches. DEBUG1 should never be used in permanent code in core
Postgres.

DEBUG2 logs that can be triggered by queries should have content
that's fully dependent on these queries (and GUC configurations). So
no logs related to caches, that might or might not be instantiated
before already, nor logs that might fire based on a concurrent other
backend doing queries or autovacuum having run or not having run. For
background workers these requirements don't apply, there they can be
used as long as the message is deemed important enough to be shown
when a user configures log_min_messages=debug.

DEBUG3-5 logs are for any other debug logs that might be useful, at
varying levels of noise. DEBUG3 should fire at most once per query,
DEBUG4 usually less than 10, and DEBUG5 anything above.