Re: Issue enabling track_counts to launch autovacuum in 9.4.5

On Wed, Mar 2, 2016 at 4:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> 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.
​