Re: Reduce DEBUG level of catcache refreshing messages

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

+1

> 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.

Yeah, I think stability is a useful expectation for DEBUG2, but we
still need some definition of the level's content. I was thinking
perhaps that it should be used for high-level tracing of subsystem
actions; transaction start and stop being perhaps the most obvious
cases. And we don't want it to be too verbose, either.

> 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.

In a lot of cases it's going to be hard to be sure how chatty a given
log message will be in practice. So while I'm on board with "more and
more noisy", I doubt how helpful the above guidelines will be.

One thing I was noticing while perusing some of the existing usages
is that some places use DEBUG5 for totally-expected-and-uninteresting
cases, for instance this example in guc.c:

void
check_GUC_name_for_parameter_acl(const char *name)
{
/* OK if the GUC exists. */
if (find_option(name, false, true, DEBUG5) != NULL)
return;
/* Otherwise, it'd better be a valid custom GUC name. */
(void) assignable_custom_variable_name(name, false, ERROR);
}

We'd really prefer a NEVER log level there, I think, but we
don't have one. Perhaps there's an argument for inventing one,
but the path of least resistance would be to define DEBUG5 as
being meant for cases that basically nobody wants to see ever.

That would leave us with only needing to define the contents
of levels 2-4, which is a small enough set that people might
be able to generally agree on which messages go where.
As a straw man:

DEBUG2: high-level tracing of actions. Stability desired.

DEBUG3: "run of the mill" debug messages; this would be more
or less the default level. Stability still a useful property.

DEBUG4: tracing of cache-flush-sensitive behavior and other
very noisy cases.

I'm not sure if this line of thought leads to wanting more
message levels than we have, but I don't think it'd be hard
to add more if that's the conclusion.

Other thoughts? Are there constraints or use cases we've
not accounted for yet?

regards, tom lane