EmitWarningsOnPlaceholders is too quiet

Tom Lane wrote:

I notice that EmitWarningsOnPlaceholders produces its warning messages
at elog level INFO, which makes it nearly useless for bogus custom
variable settings for a preloaded module: the only place such a module
can warn is in the postmaster log, but INFO is too low to go into the
postmaster log by default.

Perhaps we should use WARNING instead?

(I'm actually kind of wondering what the INFO elog level is good for,
as this is just about the only use and it seems wrong.)

+1 for one less logging level.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

(I'm actually kind of wondering what the INFO elog level is good for,
as this is just about the only use and it seems wrong.)

+1 for one less logging level.

I rememebered what INFO is for: it's the elevel that VACUUM VERBOSE
uses to ensure that its output gets seen at the client. (I missed
that in my first grep because vacuum's elog/ereport calls don't use
INFO as a hard-wired elevel.) So we probably can't get rid of it.
But that makes it even more clear IMHO that EmitWarningsOnPlaceholders
shouldn't be using it. It's not intended for error/warning types of
uses, but for verbose logging.

regards, tom lane

I wrote:

I rememebered what INFO is for: it's the elevel that VACUUM VERBOSE
uses to ensure that its output gets seen at the client. (I missed
that in my first grep because vacuum's elog/ereport calls don't use
INFO as a hard-wired elevel.) So we probably can't get rid of it.
But that makes it even more clear IMHO that EmitWarningsOnPlaceholders
shouldn't be using it. It's not intended for error/warning types of
uses, but for verbose logging.

After a more careful grep, here are all the uses of INFO elog level:

VACUUM/ANALYZE/CLUSTER VERBOSE
NOTIFY, in a standalone backend
guc.c's set_config_option, to bleat about bad config settings obtained from
ALTER USER or ALTER DATABASE during connection startup
guc.c's EmitWarningsOnPlaceholders, to bleat about bad custom variables

Also, most of the PLs have ways for users to emit messages at INFO
elevel, but whether a user uses that in a consistent way is not our
problem.

I'm of the opinion that guc.c is in error here, and what it should be
using for its purposes is WARNING. Objections?

regards, tom lane