public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Fujii Masao <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: pgsql: Reduce log level of some logical decoding messages from LOG to D
Date: Sun, 12 Apr 2026 13:55:26 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHGQGwF5Z59Lu=S88VOGNstD2d0DnaOpbv9oyPtrQFRoGLh5dw@mail.gmail.com>
References: <[email protected]>
<CA+TgmoYsu2+YAo9eLGkDp5VP-pfQ-jOoX382vS4THKHeRTNgew@mail.gmail.com>
<CAHGQGwEhtaT6qe5fN--t6HhTwBvBoZUukx-NVPpEMG9uFWHHvw@mail.gmail.com>
<CA+TgmoYwebE37qZwcNE9MKT4rt3ymP2s1M6KyRK_MGkxCYZMeg@mail.gmail.com>
<CAHGQGwFARNb_2J1Skvw5RQSsyhqUqWQgQJNDhP+v-7fzinLfOw@mail.gmail.com>
<CA+TgmoZ2+HQess2QSuZp1si17CDHw165PQROaFq0skcKJS20-g@mail.gmail.com>
<CAHGQGwFf+cpgw3T=NsGF8cxm4zx74AMCdajDda2Z7OXq9YM1mQ@mail.gmail.com>
<CAA4eK1+VwGQb5T7xH5AXS0XknGGCAVZQLbBcjq9DZikJhViX2g@mail.gmail.com>
<CAA4eK1+4wS-XY6qbhEyiF97Wc_o_t==5uzkZmZ3nKVDhpQpdOg@mail.gmail.com>
<CAHGQGwGdfn4UPF8TmDPF5CinbrtxyUCHyny_ZuXHwXgSPyb2-w@mail.gmail.com>
<CAHGQGwFXUcasXgcCKs18YVr8ZF8YyOcggcwvUm7h-J7KWgcwPQ@mail.gmail.com>
<CAA4eK1LHkjxoc6h9JEgbazASZfQ19fJLDH7jy4CLzdzqTYFKvg@mail.gmail.com>
<CAHGQGwF5Z59Lu=S88VOGNstD2d0DnaOpbv9oyPtrQFRoGLh5dw@mail.gmail.com>
Fujii Masao <[email protected]> writes:
> Thanks for the review! I've pushed the patch.
de74d1e9a has had a surprising consequence. Coverity has started to
whine like this about each use of ereport(LogicalDecodingLogLevel():
>>> CID 1691470: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
>>> "((MyBackendType == B_BACKEND) ? 14 : 15) >= 21" is always false regardless of the values of its operands. This occurs as the logical second operand of "&&".
1975 ereport(LogicalDecodingLogLevel(),
1976 errmsg("logical decoding found consistent point at %X/%08X",
1977 LSN_FORMAT_ARGS(lsn)),
1978 errdetail("Logical decoding will begin using saved snapshot."));
It's right of course: neither log level is >= ERROR. I don't see
why that would constitute a bug, so this is just useless nannyism
from Coverity. We could dismiss these complaints as false positives,
but the prospect of having to do that repeatedly in future isn't
attractive. I wonder if anyone sees a way to rewrite to dodge
this complaint. The only thing I can think of is to turn
LogicalDecodingLogLevel() into an out-of-line function, which I
think would silence it ... but I might be wrong, and anyway that's
not a very attractive solution either. Anybody have a better idea?
regards, tom lane
view thread (15+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: pgsql: Reduce log level of some logical decoding messages from LOG to D
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox