Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)CommandPrompt(dot)com>, Devrim GÜNDÜZ <devrim(at)CommandPrompt(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Server does not start when log_statement_stats is set to on
Date: 2008-03-21 19:49:10
Message-ID: 200803211949.m2LJnAM12537@momjian.us (view raw or flat)
Thread:
Lists: pgsql-bugs
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(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

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

In response to

Responses

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2008-03-21 19:58:03
Subject: Re: BUG #3822: Nonstandard precedence for comparison operators
Previous:From: Dave PageDate: 2008-03-21 19:10:15
Subject: Re: BUG #4048: Can't install pltcl

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group