Re: Server does not start when log_statement_stats is set to on

I am discarding this thread from the patches queue. We have fixed some
of it so a LOG message is issued for invalid postgresql.conf
combinations.  We could do more, but there doesn't seem to be a clear
TODO here.

---------------------------------------------------------------------------

Tom Lane wrote:
> I wrote:
> > The whole idea sounds pretty shaky to me, and definitely not
> > something to change in late beta.  LOG we could do now without
> > risking breaking anything.
>
> Poking around a bit more, I notice that there are already some places
> that do it the way I was thinking of, eg in commands/variable.c:
>
>             if (!new_tz)
>             {
>                 ereport((source >= PGC_S_INTERACTIVE) ? ERROR : LOG,
>                         (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>                          errmsg("unrecognized time zone name: \"%s\"",
>                                 value)));
>                 return NULL;
>             }
>
> However, even this is not really good enough: in the event of a wrong
> entry inserted into postgresql.conf, this coding will result in every
> extant backend emitting the same LOG message at SIGHUP.  That's
> annoying.  The right way to do it is as illustrated in
> set_config_option(): only the postmaster should log at LOG level,
> everyone else should be down around DEBUG2 (if not lower).
>
> That's getting to be a bit complicated to replicate in N places, though.
> Plus if we ever want to make it work like Alvaro is thinking of, we'd
> have to go back and change all those places again.  So I propose
> inventing a function
>
>     int guc_complaint_level(GucSource source)
>
> that encapsulates this logic.  The correct coding for specialized
> error messages in assign-hook routines would then be like
>
>             if (!new_tz)
>             {
>                 ereport(guc_complaint_level(source),
>                         (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>                          errmsg("unrecognized time zone name: \"%s\"",
>                                 value)));
>                 return NULL;
>             }
>
> giving us only one place to change to alter this logic.
>
> Comments, objections?
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

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

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