From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@gmail.com>
cc: Amit Kapila <amit.kapila16@gmail.com>,
 Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Reduce log level of some logical decoding messages from
 LOG to D
In-reply-to: 
 <CAHGQGwF5Z59Lu=S88VOGNstD2d0DnaOpbv9oyPtrQFRoGLh5dw@mail.gmail.com>
References: <E1w7pJ5-002Q6p-10@gemulon.postgresql.org>
 <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>
Comments: In-reply-to Fujii Masao <masao.fujii@gmail.com>
	message dated "Fri, 10 Apr 2026 23:01:41 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <340985.1776016526.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 12 Apr 2026 13:55:26 -0400
Message-ID: <340986.1776016526@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/340986.1776016526%40sss.pgh.pa.us>
Precedence: bulk

Fujii Masao <masao.fujii@gmail.com> 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 =3D=3D B_BACKEND) ? 14 : 15) >=3D 21" is always f=
alse 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 >=3D 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