Re: effective_cache_size vs units

Is there any special reason why I can't use "Mb" and "Gb" and such for
effective_cache_size, the way I can for say shared_buffers?

//Magnus

Magnus Hagander wrote:
> Is there any special reason why I can't use "Mb" and "Gb" and such
> for effective_cache_size, the way I can for say shared_buffers?

You can't use "Mb" or "Gb" for shared_buffers either, because those are
not accepted units.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Mon, 2006-12-18 at 22:08 +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > Is there any special reason why I can't use "Mb" and "Gb" and such
> > for effective_cache_size, the way I can for say shared_buffers?
>
> You can't use "Mb" or "Gb" for shared_buffers either, because those are
> not accepted units.

Magnus,

Here is a link that may help:
http://www.postgresql.org/docs/8.2/static/config-setting.html

It looks like it is very pedantic about the input it can receive.

Sincerely,

Joshua D. Drake

>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Is there any special reason why I can't use "Mb" and "Gb" and such
>> for effective_cache_size, the way I can for say shared_buffers?
>
> You can't use "Mb" or "Gb" for shared_buffers either, because those are
> not accepted units.
>

Oh, you mean MB vs Mb. Man, it had to be that simple :)

Sorry about the noise.

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Oh, you mean MB vs Mb. Man, it had to be that simple :)

ISTM we had discussed whether guc.c should accept units strings in
a case-insensitive manner, and the forces of pedantry won the first
round. Shall we reopen that argument?

regards, tom lane

On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > Oh, you mean MB vs Mb. Man, it had to be that simple :)
>
> ISTM we had discussed whether guc.c should accept units strings in
> a case-insensitive manner, and the forces of pedantry won the first
> round. Shall we reopen that argument?

I don't think that anyone is going to think, oh I am using 1000 Mega Bit
of ram. Mb == MB in this case. That being said, it is documented and I
don't know that it makes that much difference as long as the
documentation is clear.

Hmm perhaps perhaps a quick statement to the effect of what is legal in
the postgresql.conf? E.g;

#
# When setting memory parameters you may used a shortened sytanx e.g.,
# 1024MB or 1GB is 1 Gigabyte of ram. Note that MB/GB is capitalized.
#

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On Mon, Dec 18, 2006 at 08:56:22PM -0800, Joshua D. Drake wrote:
> On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
> > Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > > Oh, you mean MB vs Mb. Man, it had to be that simple :)
> >
> > ISTM we had discussed whether guc.c should accept units strings in
> > a case-insensitive manner, and the forces of pedantry won the first
> > round. Shall we reopen that argument?
>
> I don't think that anyone is going to think, oh I am using 1000 Mega Bit
> of ram. Mb == MB in this case. That being said, it is documented and I
> don't know that it makes that much difference as long as the
> documentation is clear.

Is it possible to add an error hint to the message? Along the line of
"HINT: Did you perhaps get your casing wrong" (with better wording, of
course).

//Magnus

Magnus Hagander wrote:
> Is it possible to add an error hint to the message? Along the line of
> "HINT: Did you perhaps get your casing wrong" (with better wording,
> of course).

Or how about we just make everything case-insensitive -- but
case-preserving! -- on Windows only?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Tue, Dec 19, 2006 at 10:01:05AM +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > Is it possible to add an error hint to the message? Along the line of
> > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > of course).
>
> Or how about we just make everything case-insensitive -- but
> case-preserving! -- on Windows only?

Wouldn't help me one bit, I had this problem on the install for
search.postgresql.org, which runs on Ubuntu Linux.

//Magnus

On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > Is it possible to add an error hint to the message? Along the line of
> > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > of course).
>
> Or how about we just make everything case-insensitive -- but
> case-preserving! -- on Windows only?

Or we could simply add a helpful line to the postgresql.conf.

Sincerely,

Joshua D. Drake

>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On Tue, 2006-12-19 at 13:32 -0800, Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> > > Is it possible to add an error hint to the message? Along the line of
> > > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > > of course).
> >
> > Or how about we just make everything case-insensitive -- but
> > case-preserving! -- on Windows only?
>
> Or we could simply add a helpful line to the postgresql.conf.

Index: postgresql.conf.sample
===================================================================
RCS
file: /projects/cvsroot/pgsql/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.199
diff -c -r1.199 postgresql.conf.sample
*** postgresql.conf.sample 21 Nov 2006 01:23:37 -0000 1.199
--- postgresql.conf.sample 19 Dec 2006 21:36:28 -0000
***************
*** 24,29 ****
--- 24,33 ----
# settings, which are marked below, require a server shutdown and
restart
# to take effect.

+ #
+ # Any memory setting may use a shortened notation such as 1024MB or
1GB.
+ # Please take note of the case next to the unit size.
+ #

#---------------------------------------------------------------------------
# FILE LOCATIONS

>
> Sincerely,
>
> Joshua D. Drake
>
>
> >
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> > > Is it possible to add an error hint to the message? Along the line of
> > > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > > of course).
> >
> > Or how about we just make everything case-insensitive -- but
> > case-preserving! -- on Windows only?
>
> Or we could simply add a helpful line to the postgresql.conf.

Looking at the documentation I see:

(possibly different) unit can also be specified explicitly. Valid
memory units are <literal>kB</literal> (kilobytes),
<literal>MB</literal> (megabytes), and <literal>GB</literal>
(gigabytes); valid time units are <literal>ms</literal>
(milliseconds), <literal>s</literal> (seconds),
<literal>min</literal> (minutes), <literal>h</literal> (hours),
and <literal>d</literal> (days). Note that the multiplier for
memory units is 1024, not 1000.

The only value to being case-sensitive in this area is to allow
upper/lower case with different meanings, but I don't see us using that,
so why do we bother caring about the case?

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

On Tue, 2006-12-19 at 16:47 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > > Magnus Hagander wrote:
> > > > Is it possible to add an error hint to the message? Along the line of
> > > > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > > > of course).
> > >
> > > Or how about we just make everything case-insensitive -- but
> > > case-preserving! -- on Windows only?
> >
> > Or we could simply add a helpful line to the postgresql.conf.
>
> Looking at the documentation I see:
>
> (possibly different) unit can also be specified explicitly. Valid
> memory units are <literal>kB</literal> (kilobytes),
> <literal>MB</literal> (megabytes), and <literal>GB</literal>
> (gigabytes); valid time units are <literal>ms</literal>
> (milliseconds), <literal>s</literal> (seconds),
> <literal>min</literal> (minutes), <literal>h</literal> (hours),
> and <literal>d</literal> (days). Note that the multiplier for
> memory units is 1024, not 1000.
>
> The only value to being case-sensitive in this area is to allow
> upper/lower case with different meanings, but I don't see us using that,
> so why do we bother caring about the case?

Because it is technically correct :).

Sincerely,

Joshua D. Drake

>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> + #
> + # Any memory setting may use a shortened notation such as 1024MB or
> 1GB.
> + # Please take note of the case next to the unit size.
> + #

Well, if you add that, you should also list all the other valid units.
But it's quite redundant, because nearly all the parameters that take
units are already listed with units in the default file. (Which makes
Magnus's mistake all the more curios.)

In my mind, this is pretty silly. There is no reputable precedent
anywhere for variant capitalization in unit names. Next thing we point
out that zeros are significant in the interior of numbers, or what?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Joshua D. Drake wrote:
>> + #
>> + # Any memory setting may use a shortened notation such as 1024MB or
>> 1GB.
>> + # Please take note of the case next to the unit size.
>> + #
>
> Well, if you add that, you should also list all the other valid units.
> But it's quite redundant, because nearly all the parameters that take
> units are already listed with units in the default file. (Which makes
> Magnus's mistake all the more curios.)
>

The explanation is pretty simple. I was in a hurry to set it, just
opened the file up in vi, jumped to effective cache size, and set it. I
remembered that "hey, I can spec it in Mb now, I don't have to think,
brilliant", and just typed it in. Restarted pg and noticed it wouldn't
start...

Had I actually read through all the documentation before I did it, it
certainly wouldn't have been a problem. I doubt many users actually do
that, though. In most cases, I just assume they would just assume they
can't use units on it because the default value in the file doesn't have
units.

And frankly, this is the only case I can recall having seen when the
input is actually case sensitive between Mb and MB. Could be that I'm
not exposed to enough systems that take such input, but I can't imagine
there aren't others who would make the same mistake.

//Magnus

On Tue, 2006-12-19 at 22:59 +0100, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > + #
> > + # Any memory setting may use a shortened notation such as 1024MB or
> > 1GB.
> > + # Please take note of the case next to the unit size.
> > + #
>
> Well, if you add that, you should also list all the other valid units.

Why? It is clearly just an example.

> But it's quite redundant, because nearly all the parameters that take
> units are already listed with units in the default file. (Which makes
> Magnus's mistake all the more curios.)

Not really, most people I know don't even consider the difference
between MB and Mb... shoot most people think that 1000MB equals one
Gigabyte.

>
> In my mind, this is pretty silly. There is no reputable precedent
> anywhere for variant capitalization in unit names.

I am not suggestion variant capitalization. I am suggestion a simple
document patch to help eliminate what may not be obvious.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Bruce Momjian wrote:
> The only value to being case-sensitive in this area is to allow
> upper/lower case with different meanings, but I don't see us using
> that, so why do we bother caring about the case?

Because the units are what they are.

In broader terms, we may one day want to have other units or a
units-aware data type, so introducing incompatibilities now would be
unfortunate.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

> > In my mind, this is pretty silly. There is no reputable precedent
> > anywhere for variant capitalization in unit names.
>
> I am not suggestion variant capitalization. I am suggestion a simple
> document patch to help eliminate what may not be obvious.

Good lord... *suggesting*

Joshua D. Drake

> Sincerely,
>
> Joshua D. Drake
>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Oh, you mean MB vs Mb. Man, it had to be that simple :)
>
> ISTM we had discussed whether guc.c should accept units strings in
> a case-insensitive manner, and the forces of pedantry won the first
> round. Shall we reopen that argument?

Nope, I just checked back in the archive and that's not what happened. There
was an extended discussion about whether to force users to use the silly KiB,
MiB, etc units. Thankfully the pedants lost that round soundly.

There was no particular discussion about case sensitivity though Simon made
the case for user-friendly behaviour:

> I think we are safe assume to that
>
> kB = KB = kb = Kb = 1024 bytes
>
> mB = MB = mb = Mb = 1024 * 1024 bytes
>
> gB = GB = gb = Gb = 1024 * 1024 * 1024 bytes
>
> There's no value in forcing the use of specific case and it will be just
> confusing for people.

http://archives.postgresql.org/pgsql-hackers/2006-07/msg01253.php

And Jim Nasby said something similar:

> Forcing people to use a specific casing scheme is just going to lead to
> confusion and user frustration. If there's not a very solid *functional*
> argument for it, we shouldn't do it. Wanting to enforce a convention that
> people rarely use isn't a good reason.

http://archives.postgresql.org/pgsql-hackers/2006-07/msg01355.php

There was a lone comment from Thomas Hallgren in favour of case sensitivity in
the name of consistency. But Nasby's comment was directly in response and
nobody else piped up after that.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

On Tue, Dec 19, 2006 at 10:12:34PM +0000, Gregory Stark wrote:
>
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Magnus Hagander <magnus(at)hagander(dot)net> writes:
> >> Oh, you mean MB vs Mb. Man, it had to be that simple :)
> >
> > ISTM we had discussed whether guc.c should accept units strings in
> > a case-insensitive manner, and the forces of pedantry won the first
> > round. Shall we reopen that argument?
>
> Nope, I just checked back in the archive and that's not what happened. There
> was an extended discussion about whether to force users to use the silly KiB,
> MiB, etc units. Thankfully the pedants lost that round soundly.
>
> There was no particular discussion about case sensitivity though Simon made
> the case for user-friendly behaviour:
>
> > I think we are safe assume to that
> >
> > kB = KB = kb = Kb = 1024 bytes
> >
> > mB = MB = mb = Mb = 1024 * 1024 bytes
> >
> > gB = GB = gb = Gb = 1024 * 1024 * 1024 bytes
> >
> > There's no value in forcing the use of specific case and it will be just
> > confusing for people.
>
> http://archives.postgresql.org/pgsql-hackers/2006-07/msg01253.php
>
> And Jim Nasby said something similar:
>
> > Forcing people to use a specific casing scheme is just going to lead to
> > confusion and user frustration. If there's not a very solid *functional*
> > argument for it, we shouldn't do it. Wanting to enforce a convention that
> > people rarely use isn't a good reason.
>
> http://archives.postgresql.org/pgsql-hackers/2006-07/msg01355.php
>
> There was a lone comment from Thomas Hallgren in favour of case sensitivity in
> the name of consistency. But Nasby's comment was directly in response and
> nobody else piped up after that.
>

My one comment is that a little 'b' is used to indicate bits normally
and a capital 'B' is used to indicate bytes. So
kb = '1024 bits'
kB = '1024 bytes'
...

I do think that whether or not the k/m/g is upper case or lower case
is immaterial.

Ken
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

Magnus Hagander wrote:
> In most cases, I just assume they would just assume
> they can't use units on it because the default value in the file
> doesn't have units.

But the default value *does* have units.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> In most cases, I just assume they would just assume
>> they can't use units on it because the default value in the file
>> doesn't have units.
>
> But the default value *does* have units.
>
It does? Didn't in my file. I must've overwritten it with a config file
from some earlier beta (or snapshot) that didn't have it or so - my
default value certainly didn't have it ;-)

//Magnus

On Tue, 2006-12-19 at 23:39 +0100, Magnus Hagander wrote:
> Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> >> In most cases, I just assume they would just assume
> >> they can't use units on it because the default value in the file
> >> doesn't have units.
> >
> > But the default value *does* have units.
> >
> It does? Didn't in my file. I must've overwritten it with a config file
> from some earlier beta (or snapshot) that didn't have it or so - my
> default value certainly didn't have it ;-)

Just to confirm, yes the sample I submitted a patch for does have units.

Joshua D. Drake

>
> //Magnus
>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> I am not suggestion variant capitalization. I am suggestion a simple
> document patch to help eliminate what may not be obvious.

Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of "invalid integer". I'd
imagine "invalid memory unit: TB" would be less confusing.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

"Kenneth Marshall" <ktm(at)it(dot)is(dot)rice(dot)edu> writes:

> My one comment is that a little 'b' is used to indicate bits normally
> and a capital 'B' is used to indicate bytes. So
> kb = '1024 bits'
> kB = '1024 bytes'
> I do think that whether or not the k/m/g is upper case or lower case
> is immaterial.

Yes, well, no actually there are standard capitalizations for the k and M and
G. A lowercase g is a gram and a lowercase m means "milli-".

But I think that only gets you as far as concluding that Postgres ought to
consistently use kB MB and GB in its own output. Which afaik it does.

To reach a conclusion about whether it should restrict valid user input
similarly you would have to make some sort of argument about what problems it
could lead to if we allow users to be sloppy.

I could see such an argument being made but it requires a lot of speculation
about hypothetical future parameters and future problems. When we have known
real problems today.

And yes, btw, the case sensitivity of these units had already surprised and
bothered me earlier and I failed to mention it at the time.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:
>
> "Kenneth Marshall" <ktm(at)it(dot)is(dot)rice(dot)edu> writes:
>
> > My one comment is that a little 'b' is used to indicate bits normally
> > and a capital 'B' is used to indicate bytes. So
> > kb = '1024 bits'
> > kB = '1024 bytes'
> > I do think that whether or not the k/m/g is upper case or lower case
> > is immaterial.
>
> Yes, well, no actually there are standard capitalizations for the k and M and
> G. A lowercase g is a gram and a lowercase m means "milli-".

I will have 150 grams of shared memory, please.

> But I think that only gets you as far as concluding that Postgres ought to
> consistently use kB MB and GB in its own output. Which afaik it does.
>
> To reach a conclusion about whether it should restrict valid user input
> similarly you would have to make some sort of argument about what problems it
> could lead to if we allow users to be sloppy.
>
> I could see such an argument being made but it requires a lot of speculation
> about hypothetical future parameters and future problems. When we have known
> real problems today.
>
> And yes, btw, the case sensitivity of these units had already surprised and
> bothered me earlier and I failed to mention it at the time.

Agreed. However, I see 'ms' as milliseconds, so perhaps the M vs. m is
already in use. I think we at least need to document the case
sensitivity and improve the error message.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Perhaps it would be more effective to clarify the error message? Right
> now it just says something to the effect of "invalid integer". I'd
> imagine "invalid memory unit: TB" would be less confusing.

+1 on that, but I think we should just accept the strings
case-insensitively, too. SQL in general is not case sensitive for
keywords, and neither is anything else in the postgresql.conf file,
so I argue it's inconsistent to be strict about the case for units.

Nor do I believe that we'd ever accept a future patch that made
the distinction between "kb" and "kB" significant --- if you think
people are confused now, just imagine what would happen then.

regards, tom lane

On Tue, 2006-12-19 at 19:16 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Perhaps it would be more effective to clarify the error message? Right
> > now it just says something to the effect of "invalid integer". I'd
> > imagine "invalid memory unit: TB" would be less confusing.
>
> +1 on that, but I think we should just accept the strings
> case-insensitively, too. SQL in general is not case sensitive for
> keywords, and neither is anything else in the postgresql.conf file,
> so I argue it's inconsistent to be strict about the case for units.

Hello,

Attached is a simple patch that replaces strcmp() with pg_strcasecmp().
Thanks to AndrewS for pointing out that I shouldn't use strcasecp().

I compiled and installed, ran an initdb with 32mb (versus 32MB) and it
seems to work correctly with a show shared_buffers;

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Tom Lane wrote:
> Nor do I believe that we'd ever accept a future patch that made
> the distinction between "kb" and "kB" significant --- if you think
> people are confused now, just imagine what would happen then.

As I said elsewhere, I'd imagine future functionality like a units-aware
data type, which has been talked about several times, and then this
would be really bad.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Joshua D. Drake wrote:
> I compiled and installed, ran an initdb with 32mb (versus 32MB) and
> it seems to work correctly with a show shared_buffers;

Did it actually allocate 32 millibits of shared buffers?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Tom Lane wrote:
> +1 on that, but I think we should just accept the strings
> case-insensitively, too.

I think if we'd allow this to spread, documentation, example files and
other material would use it inconsistently, and even more people would
be confused and it would make us look silly.

It's not like anyone has pointed out a real use case here. The default
file has the units already, so it's not like they're hard to guess.
And Magnus's issue was that the error message was confusing. So let's
fix that.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Wed, 2006-12-20 at 02:19 +0100, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > I compiled and installed, ran an initdb with 32mb (versus 32MB) and
> > it seems to work correctly with a show shared_buffers;
>
> Did it actually allocate 32 millibits of shared buffers?

Funny :)

Joshua D. Drake

>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

> Hello,
>
> Attached is a simple patch that replaces strcmp() with pg_strcasecmp().
> Thanks to AndrewS for pointing out that I shouldn't use strcasecp().
>

That should be AndrewD :)

J

> I compiled and installed, ran an initdb with 32mb (versus 32MB) and it
> seems to work correctly with a show shared_buffers;
>
> Sincerely,
>
> Joshua D. Drake
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> Nor do I believe that we'd ever accept a future patch that made
>> the distinction between "kb" and "kB" significant --- if you think
>> people are confused now, just imagine what would happen then.

> As I said elsewhere, I'd imagine future functionality like a units-aware
> data type, which has been talked about several times, and then this
> would be really bad.

Only if the units-aware datatype insisted on case-sensitive units, which
is at variance with the SQL spec's treatment of keywords, the existing
practice in postgresql.conf, the existing practice in our datatypes such
as timestamp and interval:

regression=# select '20-dec-2006'::timestamp;
timestamp
---------------------
2006-12-20 00:00:00
(1 row)

regression=# select '20-DEC-2006'::timestamp;
timestamp
---------------------
2006-12-20 00:00:00
(1 row)

regression=# select '20-Dec-2006 America/New_York'::timestamptz;
timestamptz
------------------------
2006-12-20 00:00:00-05
(1 row)

regression=# select '20-Dec-2006 AMERICA/NEW_york'::timestamptz;
timestamptz
------------------------
2006-12-20 00:00:00-05
(1 row)

regression=# select '20-Dec-2006 PST'::timestamptz;
timestamptz
------------------------
2006-12-20 03:00:00-05
(1 row)

regression=# select '20-Dec-2006 pst'::timestamptz;
timestamptz
------------------------
2006-12-20 03:00:00-05
(1 row)

regression=# select '1 day'::interval;
interval
----------
1 day
(1 row)

regression=# select '1 DAY'::interval;
interval
----------
1 day
(1 row)

and in general, there is simply not any other part of Postgres or SQL
that you can point to that supports the idea that case sensitivity
for keywords is expected behavior. So I think we'd flat-out reject
any such datatype.

(Hmm, I wonder what Tom Dunstan's enum patch does about case
sensitivity...)

regards, tom lane

Peter Eisentraut wrote:
> Tom Lane wrote:
>> Nor do I believe that we'd ever accept a future patch that made
>> the distinction between "kb" and "kB" significant --- if you think
>> people are confused now, just imagine what would happen then.
>
> As I said elsewhere, I'd imagine future functionality like a units-aware
> data type, which has been talked about several times, and then this
> would be really bad.
>

Most if not all of us here with computer knowledge (particularly at the
programming level) know the difference between capital and lowercase
memory/data size abbreviations.

Case insensitive size measurements don't matter if you actually know
what the abbreviations mean.

The case where case matters ;-) is b and B (bits and Bytes for those
that don't know the diff)

And if you don't know the difference between m and M - one is a portion
of and the other is a multiple of. So mB would technically mean 0.001 of
a byte. I'd like to see you allocate that!!

As is the case of many english words - the context of the usage makes a
big difference in the interpretation.

Given that the purpose of the effective_cache_size setting (and similar)
is to specify the amount of memory you want allocated/limited to, then
that context allows you to assume that all unit abbreviations are
specifying bytes/kilobytes/megabytes/gigabytes and not
bits/kilobits/millibits/millibytes etc

As for the future - well, TB is getting more common, petabytes of
storage has been talked about, 64bit systems can access exabytes of ram.
Next would be zettabytes and yottabytes.

Unless we start a roman numeral system for amounts bigger than that then
I seriously doubt that we will hit any confusion with future usage. (and
I doubt in our lifetimes) Though I suppose with storage expansion rates
increasing the way they have the last few years we may be using
yottabyte hard drives on our 256bit systems with 512 zettabytes of ram
in about 15 years ;-)

That might make it around the end of life for the 8.0 branch so maybe we
need to consider handling these future storage needs soon?

Maybe in 40 years we will all retire with mega-yotta-byte drives in our
pda watches?

As for units aware datatypes - what options are available will need to
be decided at implementation time. Will we allow megabit (Mb) size
allocations or only megabyte? I would say bits would be clearly
specified as such (bit instead of b)

Let's skip any flame wars on this and concentrate on the humorous future
storage sizes.

--

Shane Ambler
pgSQL(at)007Marketing(dot)com

Get Sheeky @ http://Sheeky.Biz

On 12/19/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think we should just accept the strings case-insensitively, too.

While acknowledging Peter's pedantically-correct points, I say +1 for
ease of use.

--
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 3rd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:

> On 12/19/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think we should just accept the strings case-insensitively, too.
>
> While acknowledging Peter's pedantically-correct points, I say +1 for
> ease of use.

+1. I spend some time walking people through tuning issues
by phone or IM. Anything that complicates supporting users or
frustrates users for no actual benefit is a bad thing.

(And this is unrelated to any theoretical units-aware data type -
we might well be interested in milliwatts and megawatts in a
datatype, but in the configuration file we're unlikely to ever
need to configure things in units of millibits).

Cheers,
Steve

Tom Lane wrote:

> (Hmm, I wonder what Tom Dunstan's enum patch does about case
> sensitivity...)

Currently enum labels are case sensitive. I was a bit ambivalent about
it... case insensitivity can lead to less surprises in some cases, but
many programming languages that have enums are case sensitive, and so
this wouldn't be a direct map for them. OTOH, if someone's doing evil
things like sticking labels that differ only in case into an enum,
perhaps they *should* be dissuaded. :)

The question is where does it end, though? Should we treat letters with
accents and umlauts as equivalent as well? Do we remove punctuation
characters? It gets into a (for me) more murky localization issue, and
I'm not familiar with the postgresql apis for handling that. Maybe it's
easy.

Since we basically accept any old thing into an enum label, I think we
probably shouldn't muck with it. If we want to have some sort of
normalized version, then we should probably restrict the characters that
we accept fairly severely.

Also note that enum values are far more likely to be set by application
code than by a human typing the value in directly, so in that sense the
need for case insensitivity seems somewhat diminished.

I suppose we should think about mysql refugees at some point, though. I
wonder what they do. The documentation is silent on the matter (and all
their examples are in lower case). Mysql is generally case insensitive,
right?

Cheers

Tom

Am Mittwoch, 20. Dezember 2006 13:42 schrieb Tom Dunstan:
> I suppose we should think about mysql refugees at some point, though. I
> wonder what they do. The documentation is silent on the matter (and all
> their examples are in lower case). Mysql is generally case insensitive,
> right?

Maybe you can make sense of this, but I can't ...

mysql> create table test (a int, b enum ('x', 'X', 'y'));
Query OK, 0 rows affected, 1 warning (0.02 sec)

mysql> show warnings;
+-------+------+---------------------------------------------+
| Level | Code | Message |
+-------+------+---------------------------------------------+
| Note | 1291 | Column 'b' has duplicated value 'x' in ENUM |
+-------+------+---------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into test values (1, 'x');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values (1, 'X');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values (1, 'y');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values (1, 'Y');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values (1, 'z');
Query OK, 1 row affected, 1 warning (0.00 sec)

## You think that was funny -- now watch this:

mysql> select * from test;
+------+------+
| a | b |
+------+------+
| 1 | x |
| 1 | x |
| 1 | y |
| 1 | y |
| 1 | |
+------+------+
5 rows in set (0.00 sec)

mysql> drop table test;
Query OK, 0 rows affected (0.00 sec)

mysql> create table test (a int, b enum ('ä', 'Ä', ' ', ' '));
## Above is a-diaeresis, A-diaeresis.
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql> show warnings;
+-------+------+---------------------------------------------+
| Level | Code | Message |
+-------+------+---------------------------------------------+
| Note | 1291 | Column 'b' has duplicated value '?' in ENUM | # literal ?
| Note | 1291 | Column 'b' has duplicated value '' in ENUM |
+-------+------+---------------------------------------------+
2 rows in set (0.00 sec)

mysql> insert into test values (1, ' ');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values (1, ' ');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values (1, ' ');
Query OK, 1 row affected (0.01 sec)

mysql> insert into test values (1, ' |');
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+----------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------+
| Warning | 1265 | Data truncated for column 'b' at row 1 |
+---------+------+----------------------------------------+
1 row in set (0.00 sec)

mysql> select distinct * from test;
+------+------+
| a | b |
+------+------+
| 1 | ä |
| 1 | |
| 1 | |
+------+------+

Better not imitate that.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Am Mittwoch, 20. Dezember 2006 13:42 schrieb Tom Dunstan:
>
>> I suppose we should think about mysql refugees at some point, though. I
>> wonder what they do. The documentation is silent on the matter (and all
>> their examples are in lower case). Mysql is generally case insensitive,
>> right?
>>
>
> Maybe you can make sense of this, but I can't ...
>
>
>
[lots of amusing non-orthogonal braindead stuff ...]
>
> Better not imitate that.
>
>

The MySQL treatment of enums is generally quite reprehensible. The
proposed patch by contrast fits quite well into our existing type
system, I think. MySQL users migrating will have a bit of work to do.

I don't think their experience has much to teach us (except how not to
do enums). We should decide on case sensitivity without having reference
to it.

cheers

andrew

On Tue, 2006-12-19 at 22:06 -0800, Steve Atkins wrote:
> On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:
>
> > On 12/19/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I think we should just accept the strings case-insensitively, too.
> >
> > While acknowledging Peter's pedantically-correct points, I say +1 for
> > ease of use.
>
> +1. I spend some time walking people through tuning issues
> by phone or IM. Anything that complicates supporting users or
> frustrates users for no actual benefit is a bad thing.
>
> (And this is unrelated to any theoretical units-aware data type -
> we might well be interested in milliwatts and megawatts in a
> datatype, but in the configuration file we're unlikely to ever
> need to configure things in units of millibits).

Where we at on this?

Joshua D. Drake

>
> Cheers,
> Steve
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> On 12/19/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I think we should just accept the strings case-insensitively, too.

> Where we at on this?

Anyone against making it case-insensitive, speak now or hold your peace.

regards, tom lane

>>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

TL> Anyone against making it case-insensitive, speak now or hold your
TL> peace.

SI-units are inherently case-sensitive. The obvious example is that
now you will allow people to specify an amount in millibytes, while
interpreting it in megabytes.

You are trying to interpret valid input as misspellings based on
context, and then you silently guess at what the user really meant.
That's MySQL behaviour!

/Benny

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
> >>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> TL> Anyone against making it case-insensitive, speak now or hold your
> TL> peace.
>
> SI-units are inherently case-sensitive [...]

As a notorious lurker, set my weight to one mg (choose the case ;-)

I'd tend to keep case sensitivity, but will hold my peace regardless of
outcome.

Thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFkkDWBcgs9XrR2kYRAmKFAJwPMOwl+IbCbMQvszn9RKpXRW3N6ACfbwne
juGsqnMsj2BMyCO+BjP9hq4=
=KCiY
-----END PGP SIGNATURE-----

On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
> >>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> TL> Anyone against making it case-insensitive, speak now or hold your
> TL> peace.
>
> SI-units are inherently case-sensitive. The obvious example is that
> now you will allow people to specify an amount in millibytes, while
> interpreting it in megabytes.

Yes, and I can't think of a single reason why we'd let people specify
anything in millibytes, or kilobits. Truth is, I bet many (if not most)
DBAs barely know that case matters in the units. And even those that do
are likely to prefer ease of use to pedantics.

As for the comments about SI datatypes and MySQL-isms, there's a hell of
a big difference between muddying the line in a config file for ease of
use and stomping on data that's actually stored in the database.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

>>>>> "JCN" == Jim C Nasby <jim(at)nasby(dot)net> writes:

JCN> Truth is, I bet many (if not most) DBAs barely know that case
JCN> matters in the units.

Sounds like the school system needs fixing, then.

/Benny

Benny Amorsen wrote:
> >>>>> "JCN" == Jim C Nasby <jim(at)nasby(dot)net> writes:
>
> JCN> Truth is, I bet many (if not most) DBAs barely know that case
> JCN> matters in the units.
>
> Sounds like the school system needs fixing, then.

Sure, but it probably shows a lot more prominently in other areas than
in unit casing though.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Benny Amorsen wrote:
> >>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> TL> Anyone against making it case-insensitive, speak now or hold your
> TL> peace.
>
> SI-units are inherently case-sensitive. The obvious example is that
> now you will allow people to specify an amount in millibytes, while
> interpreting it in megabytes.

And as Peter points out, there may be a desire to support SI-type units
in other parts of the database at some time in the future. It seems
like a questionable idea to break with convention just for ease of use.

> You are trying to interpret valid input as misspellings based on
> context, and then you silently guess at what the user really meant.
> That's MySQL behaviour!

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.

Andrew

"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

>>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

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

Units simply are not case sensitive. They are just a more or less
random collection of preexisting symbols, because that was easier than
drawing up entirely new ones. Not all are English letters, for one µ
is not. If you upper case a text with units in, the units do not
change with the rest of the text.

/Benny

Benny Amorsen <benny+usenet(at)amorsen(dot)dk> writes:
> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> TL> Personally I don't find the argument about "someday we might want
> TL> to support measurements in millibits" to be convincing at all, and
> TL> certainly it seems weaker than the argument that "units should be
> TL> case insensitive because everything else in this file is". The SQL
> TL> spec has to be considered a more relevant controlling precedent
> TL> for us than the SI units spec, and there are no case-sensitive
> TL> keywords in SQL.

> Units simply are not case sensitive. They are just a more or less
> random collection of preexisting symbols, because that was easier than
> drawing up entirely new ones. Not all are English letters, for one
> is not.

You mean "are case sensitive" right? This is not news. The point I'm
basically making is that it's not going to hurt us to restrict GUC to
supporting a subset of all-possible-units that can be treated
case-insensitively. We're already going to restrict the allowed
character set: I can guarantee you that , or anything else
outside 7-bit ASCII, will never be accepted. It's just not worth the
trouble of dealing with multiple possible encodings.

regards, tom lane

Am Donnerstag, 28. Dezember 2006 13:25 schrieb Jim C. Nasby:
> Yes, and I can't think of a single reason why we'd let people specify
> anything in millibytes, or kilobits.

How about a configuration option related to connection throughput, which is
typically measured in bits?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Donnerstag, 28. Dezember 2006 13:25 schrieb Jim C. Nasby:
>> Yes, and I can't think of a single reason why we'd let people specify
>> anything in millibytes, or kilobits.

> How about a configuration option related to connection throughput, which is
> typically measured in bits?

But at least as often in bytes. What's more, if the system really were
to accept both units, you could reasonably expect that people would get
it wrong at least half the time ...

regards, tom lane

> > Yes, and I can't think of a single reason why we'd let people
specify
> > anything in millibytes, or kilobits.
>
> How about a configuration option related to connection throughput,
which is
> typically measured in bits?

We'd use "kbit". I don't see us using "kb" in that case (or was it kB
:-).

Andreas

You just proved the case for why the units shouldn't be case sensitive:

On Dec 30, 2006, at 6:36 PM, Andrew Hammond wrote:
> 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.

Do we really want people specifying effective_cache_size in *bits*,
mega or not? I think no.

To reply to Peter's comment, yes, bits would be useful if we ever
actually have any settings relating to network bandwidth. But that's
a really big IF. IF we do eventually decide to add such a setting, I
think it would make the most sense to spell out 'bits' in the unit.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)