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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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