"David G. Johnston" <david.g.johnston@xxxxxxxxx> writes:
> The fact that the first two are only LOG level and not WARNING would seems
> like the easiest improvement to make.
Unfortunately, that would be a disimprovement, because in many common
configurations WARNING messages don't appear in the postmaster log at all.
In fact, I'd say it's a bug that the "autovacuum not started" message is
emitted as a WARNING not LOG.
Maybe we need some way of printing something at LOG priority but having
the printed text be WARNING. I'm afraid that might cause about as much
confusion as it would solve, though.
Yes, I recall this unusual situation now...
In this specific case, when we know that "WARNING: autovacuum not started because of misconfiguration" was emitted, if the previous two messages were also at WARNING would they have been emitted as well?
> It probably would help to specify, if known, whether the suspected
> mis-configuration is external or internal to PostgreSQL - i.e., do I need
> to fix postgres.conf or is something external (like the hosts file) to
> blame.
In the case of a name resolution failure, the problem is certainly
external to Postgres, but we don't have enough information to say more
than that. We could print a hint guessing at causes (like broken
/etc/host or /etc/resolv.conf files), but it would be guesses --- and
I'm afraid there's enough cross-system variation in the way this stuff is
configured that any hint would be likely to just be misleading.
I was trying to restrict it to simply internal/external though - I wouldn't care where the resolution comes other than we known that nothing in PostgreSQL is involved as a server, only as a client. So saying "its not our fault" seems appropriate and sufficient so the user doesn't spend time with ALTER SYSTEM or editing the configuration file.
> This is getting a bit deep for a rare problem like this - I think that
> making the root messages WARNING (or ERROR)
ERROR would mean that the postmaster fails to start at all. That doesn't
seem like an improvement either.
Its only a problem if the postmaster starts and we emit error...do we have FATAL that could imply the postmaster doesn't start and use ERROR if one of the optional related processes (statistics, auto-vacuum) doesn't start?
David J.
