Re: effective_cache_size vs units

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: effective_cache_size vs units
Date: 2006-12-31 01:16:45
Message-ID: 25736.1167527805@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com> writes:
> I agree. But perhaps the solution instead of failing is to throw a
> warning to the effect of "Not to be pedantic, but you said mb and
> millibits as a unit doesn't make sense in this context. Assuming you
> meant MB (MegaBits)." and then start up.
> Generally I'm against guessing what the user really wants, but in this
> case, it seems pretty difficult to guess wrong. But either way I'm
> always dead set against _silently_ guessing.

Bear in mind that the typical place for this sort of thing is
postgresql.conf, and for problems in that file the only place we can
emit a warning is into the postmaster log, which far too many users
never look at (if indeed it's going anywhere but /dev/null in the first
place). So I can't get very excited about "report a warning" as a
compromise solution.

Personally I don't find the argument about "someday we might want to
support measurements in millibits" to be convincing at all, and
certainly it seems weaker than the argument that "units should be case
insensitive because everything else in this file is". The SQL spec
has to be considered a more relevant controlling precedent for us than
the SI units spec, and there are no case-sensitive keywords in SQL.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-12-31 02:02:36 Re: TODO: GNU TLS
Previous Message Andrew Hammond 2006-12-30 23:36:24 Re: effective_cache_size vs units