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

Fujii Masao <masao(dot)fujii(at)gmail(dot)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