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 <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
