Re: pgsql: Reduce log level of some logical decoding messages from LOG to D

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