Robert Haas wrote:
A good start might be to always OUTPUT memory parameters using the
same base unit.
SHOW gives output that matches what you input.
Not for me it doesn't.
portal=# show temp_buffers;
temp_buffers
--
1024
(1 row)
portal=# set temp_buffers = '16MB';
SET
portal=#
Peter Eisentraut [EMAIL PROTECTED] writes:
temp_buffers is actually special-cased in the code because
/*
* We show the GUC var until local buffers have been initialized, and
* NLocBuffer afterwards.
*/
It is not clear to me right now why that is a good idea.
I think the
temp_buffers is actually special-cased in the code because
/*
* We show the GUC var until local buffers have been initialized, and
* NLocBuffer afterwards.
*/
It is not clear to me right now why that is a good idea. But it is only
this one paramter.
OK, well that's not so bad
Robert Haas wrote:
bits...bytes...blocks...m...M
I can't imagine that taking away the B is somehow going to
be more clear.
If clarity is the goal, I'd want the following:
a) Verbosely spelling out the units in the default config file
temp_buffers = 16 megabytes
or
temp_buffers = 16
a) Verbosely spelling out the units in the default config file
temp_buffers = 16 megabytes
or
temp_buffers = 16 milliblocks :-)
Naive users who favor cutpaste will use the verbose words
that should leave little room for confusion. Power-users
who know the short forms from the
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
But of course case insensitivity isn't going to fix that example for you.
So we're right back at the question of where we should draw the line in
trying to accept variant
This would have definitional problems of its own, however. If you interpret
K, M, and G strictly as unit-less multipliers, then
SET shared_buffers = 2 G
I don't think it would be a good idea to make them unit-less, for
exactly the reasons you mention.
We could possibly settle some of these
On Thu, 2008-09-04 at 11:51 -0400, Andrew Sullivan wrote:
On Thu, Sep 04, 2008 at 07:01:18AM -0700, Steve Atkins wrote:
Settings in postgresql.conf are currently case-insensitive. Except
for the units.
And, of course, filenames when you are using a case-sensitive
filesystem. Because
On Tue, 9 Sep 2008, Robert Haas wrote:
A good start might be to always OUTPUT memory parameters using the
same base unit.
SHOW gives output that matches what you input. If you want to see things
with consistant units, look at pg_settings:
# select name,unit,setting,current_setting(name)
Greg Smith [EMAIL PROTECTED] writes:
What I would like to see (but don't
have nearly enough time to argue in support of considering the resistance
to change here) is that this syntax:
shared_buffers=1024
Would assume the user meant 1024 *bytes*, with the server silently
rounding that up
On Tue, 9 Sep 2008, Tom Lane wrote:
How do you come to that conclusion? Leaving off the unit entirely
certainly doesn't make the user's intent clearer.
Same way I do all my conclusions in this area--talking to people in the
field regularly who've never configured a postgresql.conf before.
A good start might be to always OUTPUT memory parameters using the
same base unit.
SHOW gives output that matches what you input.
Not for me it doesn't.
portal=# show temp_buffers;
temp_buffers
--
1024
(1 row)
portal=# set temp_buffers = '16MB';
SET
portal=# show temp_buffers;
On Wed, 2008-09-03 at 11:58 +0300, Asko Oja wrote:
On Wed, Sep 3, 2008 at 11:20 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Marko Kreen wrote:
On 9/2/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Peter's objection is reasonable, as far as most people have replied.
Marko's proposal is also reasonable to most people, since they do not
wish fat fingers to cause any amount of downtime. ISTM that if you've
done this, you appreciate the feature, if not
Simon Riggs [EMAIL PROTECTED] writes:
Peter's objection is reasonable, as far as most people have replied.
Marko's proposal is also reasonable to most people, since they do not
wish fat fingers to cause any amount of downtime. ISTM that if you've
done this, you appreciate the feature, if not
Gregory Stark [EMAIL PROTECTED] writes:
I'm all for using the correct acronyms in all messages and documentation. What
I find annoying is the:
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
But of course case insensitivity isn't going to fix that example for
On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
But of course case insensitivity isn't going to fix that example for you.
So we're right back at the question of where we should draw the line in
trying to accept variant input.
Well it's not a perfect precedent but for example,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Sep 08, 2008 at 02:18:55PM +0100, Greg Stark wrote:
On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
But of course case insensitivity isn't going to fix that example for you.
So we're right back at the question of where
Greg Stark [EMAIL PROTECTED] writes:
On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
But of course case insensitivity isn't going to fix that example for you.
So we're right back at the question of where we should draw the line in
trying to accept variant input.
Well it's
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
My vote is to reject the patch and work on a config checker.
+1
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
Perhaps this would be a great place for a HINT listing all
valid inputs, if
Greg Sabino Mullane wrote:
Tom Lane wrote:
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
Perhaps this would be a great place for a HINT listing all
valid inputs, if not there already?
alvherre=# set work_mem = '1g';
ERROR: invalid value for parameter
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Tom Lane wrote:
My vote is to reject the patch and work on a config checker.
+1
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
Perhaps this would be a great place for a HINT listing all
valid inputs, if not
Gregory Stark wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Tom Lane wrote:
My vote is to reject the patch and work on a config checker.
+1
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
Perhaps this would be a great place for a HINT
Alvaro Herrera [EMAIL PROTECTED] writes:
It's good as a joke, but what if the user says '1024b'? Does it mean
1024 blocks or one kilobyte? If blocks, what size are we talking, the
usual 512 bytes, or our BLCKSZ?
For what guc would you find a unit of posix-style blocks relevant?!
--
Gregory Stark [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
It's good as a joke, but what if the user says '1024b'? Does it mean
1024 blocks or one kilobyte? If blocks, what size are we talking, the
usual 512 bytes, or our BLCKSZ?
For what guc would you find a unit of
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
It's good as a joke, but what if the user says '1024b'? Does it mean
1024 blocks or one kilobyte? If blocks, what size are we talking, the
usual 512 bytes, or our BLCKSZ?
Settings in postgresql.conf are currently case-insensitive. Except
for the units.
And, of course, filenames when you are using a case-sensitive
filesystem. Because these are things that are defined by some
convention other than the ones the PGDG made up. Since units fall
into that category,
Marko Kreen wrote:
Thirdly, please don't use standard units argument, unless you plan to
propose use of KiB, MiB, GiB at the same moment.
In defense of standard units, if the postgres docs say
Postgres will round up to the nearest power of 2
kB and MB seem very clear to me. If we want to
On Mon, 8 Sep 2008 10:32:40 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Gregory Stark wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Tom Lane wrote:
My vote is to reject the patch and work on a config checker.
+1
+1
Joshua D. Drake
--
The PostgreSQL Company since
Le jeudi 04 septembre 2008, Robert Treat a écrit :
To paraphrase, if you can't write a config file correctly before
restarting, I do not want you anywhere near any instance of a production
system
Do you really want to TCO of PostgreSQL to raise that much when the software
could help lowering
Hannu Krosing escribió:
On Wed, 2008-09-03 at 20:01 -0400, Alvaro Herrera wrote:
Yes there is --- it's the SI.
http://en.wikipedia.org/wiki/SI#SI_writing_style
I don't know about it being evil and punishment, but it's wrong.
SI defines decimal-based prefixes, where k = kilo =
On Thu, Sep 04, 2008 at 01:26:44AM +0300, Hannu Krosing wrote:
So Andrews opinion was that Mb (meaning Mbit) is different from MB (for
megabyte) and that if someone thinks that we define shared buffers in
megabits can get confused and order wrong kind of network card ?
I know it's fun to
On Sep 4, 2008, at 6:29 AM, Andrew Sullivan wrote:
On Thu, Sep 04, 2008 at 01:26:44AM +0300, Hannu Krosing wrote:
So Andrews opinion was that Mb (meaning Mbit) is different from MB
(for
megabyte) and that if someone thinks that we define shared buffers in
megabits can get confused and
On Thu, 2008-09-04 at 09:29 -0400, Andrew Sullivan wrote:
On Thu, Sep 04, 2008 at 01:26:44AM +0300, Hannu Krosing wrote:
So Andrews opinion was that Mb (meaning Mbit) is different from MB (for
megabyte) and that if someone thinks that we define shared buffers in
megabits can get confused
On Thu, Sep 04, 2008 at 07:01:18AM -0700, Steve Atkins wrote:
Settings in postgresql.conf are currently case-insensitive. Except
for the units.
And, of course, filenames when you are using a case-sensitive
filesystem. Because these are things that are defined by some
convention other than the
Marko Kreen wrote:
On 9/2/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various unambiguous, common
alternative spellings of various units. But for instance allowing MB
On Wed, Sep 3, 2008 at 11:20 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Marko Kreen wrote:
On 9/2/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various
On 9/3/08, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
On 9/2/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various unambiguous, common
On Tue, 2008-09-02 at 16:50 +0300, Peter Eisentraut wrote:
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various unambiguous, common
Hannu Krosing wrote:
On Tue, 2008-09-02 at 16:50 +0300, Peter Eisentraut wrote:
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Are you really afraid that someone would want to use mb to mean
millibits ?
As SQL is generally case insensitive, it is quite surprising to most
Greg Stark wrote:
I don't think worrying about the message we send to users is reasonable.
We can take responsibilty for the messages we output but punishing our
users to teach them a lesson is being actively user-hostile
There is no arguing that MB != Mb; nor is there anything user-hostile
On Wed, 2008-09-03 at 07:52 -0700, Joshua D. Drake wrote:
Hannu Krosing wrote:
On Tue, 2008-09-02 at 16:50 +0300, Peter Eisentraut wrote:
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Are you really afraid that someone would want to use mb to mean
millibits ?
As
On Wed, 2008-09-03 at 08:20 -0700, Joshua D. Drake wrote:
Greg Stark wrote:
I don't think worrying about the message we send to users is reasonable.
We can take responsibilty for the messages we output but punishing our
users to teach them a lesson is being actively user-hostile
There
On Wed, 03 Sep 2008 18:32:16 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:
We have had this discussion before, I even submitted a patch to
make them case insensitive. In retrospect I was wrong to submit
that patch. SQL may be case insensitive but units are not. MB !=
Mb != mb ,
For
On Wed, Sep 03, 2008 at 06:37:29PM +0300, Hannu Krosing wrote:
On Wed, 2008-09-03 at 08:20 -0700, Joshua D. Drake wrote:
There is no arguing that MB != Mb;
The whole point of this discussion is, that mostly people expect
MB == Mb = mb == mB, especially if they see weird constructs like kB
On Wed, 2008-09-03 at 09:10 -0700, Joshua Drake wrote:
If someone doesn't know the difference between Mb and MB on a
production system, I would not want them anywhere near any instance of
a production system.
I for one can make the difference, once I can zen that we are in a
domain, where
Hannu Krosing escribió:
On Wed, 2008-09-03 at 09:10 -0700, Joshua Drake wrote:
If we are going to make sweeping statements (anyone on this thread)
about user-hostile and most people, then we better define what those
mean.
Not user-hostile but rather hostile to an overworked DBA, who
On Wed, Sep 03, 2008 at 01:48:18PM -0400, Alvaro Herrera wrote:
I think the energy wasted in this discussion would be better spent in
working a the check-the-config-file feature. That would equally solve
this problem, as well as many others.
This seems like a good idea to me.
A
--
Andrew
I don't think worrying about the message we send to users is
reasonable. We can take responsibilty for the messages we output but
punishing our users to teach them a lesson is being actively user-
hostile
greg
On 3 Sep 2008, at 15:52, Joshua D. Drake [EMAIL PROTECTED] wrote:
Hannu
Sure if people want to do it the right way more power to them. What
you're talking about is punishing people when they don't live up to
your standards.
greg
On 3 Sep 2008, at 16:20, Joshua D. Drake [EMAIL PROTECTED] wrote:
Greg Stark wrote:
I don't think worrying about the message we send
On Wed, 3 Sep 2008 19:36:19 +0100
Greg Stark [EMAIL PROTECTED] wrote:
Sure if people want to do it the right way more power to them. What
you're talking about is punishing people when they don't live up to
your standards.
I think I will defer to Andrew and Alvaro's opinion on the matter.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
You do realize that misspelling unit name can cause downtime of several
minutes instead of couple seconds? We can easily do restart in couple of
seconds but the restart, look logs, launch editor, find value, change,
save, restart cycle
On Wed, 2008-09-03 at 13:48 -0400, Alvaro Herrera wrote:
Hannu Krosing escribió:
On Wed, 2008-09-03 at 09:10 -0700, Joshua Drake wrote:
If we are going to make sweeping statements (anyone on this thread)
about user-hostile and most people, then we better define what those
mean.
On Wed, 03 Sep 2008 23:10:24 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:
That would equally solve
this problem, as well as many others.
AFAIK the config file is checked now, and if the check fails, the
database won't start.
Like apachectl configcheck ... E.g; we have the ability to
Hannu Krosing escribió:
On Wed, 2008-09-03 at 13:48 -0400, Alvaro Herrera wrote:
I think the energy wasted in this discussion would be better spent in
working a the check-the-config-file feature.
What kind of checks do you have in mind. Would this be something that
works at restart, does
On Wed, 2008-09-03 at 11:45 -0700, Joshua Drake wrote:
On Wed, 3 Sep 2008 19:36:19 +0100
Greg Stark [EMAIL PROTECTED] wrote:
Sure if people want to do it the right way more power to them. What
you're talking about is punishing people when they don't live up to
your standards.
I
On Thu, 04 Sep 2008 01:26:44 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:
So Andrews opinion was that Mb (meaning Mbit) is different from MB
(for megabyte) and that if someone thinks that we define shared
buffers in megabits can get confused and order wrong kind of network
card ?
I was
Hannu Krosing escribió:
I mean, there is no known written standard, which says that Mb is
megabit, not megabyte or that you can (or can't) write kilo as K, but
some people just believe that kB is the Way and allowing people to
write kilobytes as KB or kb is evil and should be punished.
Yes
On Wednesday 03 September 2008 16:12:29 Joshua Drake wrote:
On Wed, 03 Sep 2008 23:10:24 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:
That would equally solve
this problem, as well as many others.
AFAIK the config file is checked now, and if the check fails, the
database won't
On Wed, 2008-09-03 at 20:01 -0400, Alvaro Herrera wrote:
Hannu Krosing escribió:
I mean, there is no known written standard, which says that Mb is
megabit, not megabyte or that you can (or can't) write kilo as K, but
some people just believe that kB is the Way and allowing people to
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various unambiguous, common
alternative spellings of various units. But for instance allowing MB
and Mb to mean the same thing is insane.
--
Sent via pgsql-hackers
Peter Eisentraut [EMAIL PROTECTED] writes:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various unambiguous, common
alternative spellings of various units. But for instance allowing MB and Mb
to
mean the same
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various unambiguous, common
alternative spellings of various units. But for instance allowing MB and Mb
On 9/2/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various unambiguous, common
alternative spellings of various units. But for instance allowing MB and Mb
to mean
On 9/2/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various unambiguous, common
Marko Kreen [EMAIL PROTECTED] writes:
Uh. So you want force proper units in presentations at the price
of everyday admin operations? Does not seem like a sensible tradeoff.
It didn't to anyone else when Peter wrote the current version either, but as
the person willing to actually do the work
Gregory Stark [EMAIL PROTECTED] writes:
Marko Kreen [EMAIL PROTECTED] writes:
Uh. So you want force proper units in presentations at the price
of everyday admin operations? Does not seem like a sensible tradeoff.
It didn't to anyone else when Peter wrote the current version either, but as
Anything that will reduce potential downtime should be way to go.
To me it seems that Peter uses the loudest voice and others just don't care
enough.
Using kB for kilobyte seems quite alien and confusing. I have not noticed
that to be used in software i use in my everyday work and could not find
Asko Oja [EMAIL PROTECTED] writes:
Anything that will reduce potential downtime should be way to go.
That argument didn't seem to me to be worth the electrons to rebut,
but now that someone else has repeated it, maybe I should. It's
ludicrous to claim that allowing case insensitivity here will
On 9/3/08, Tom Lane [EMAIL PROTECTED] wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Marko Kreen [EMAIL PROTECTED] writes:
Uh. So you want force proper units in presentations at the price
of everyday admin operations? Does not seem like a sensible tradeoff.
It didn't to anyone else
On 9/3/08, Tom Lane [EMAIL PROTECTED] wrote:
Asko Oja [EMAIL PROTECTED] writes:
Anything that will reduce potential downtime should be way to go.
That argument didn't seem to me to be worth the electrons to rebut,
but now that someone else has repeated it, maybe I should. It's
ludicrous
On 9/1/08, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
- In attempt to preserve maximum range of values for INT64_IS_BUSTED
systems, the code is written rather non-obvious way.
I do not personally object a bit to making the units comparisons
Current GUC units code has 2 problems:
- It requires case-sensiteive representation of units (kB).
As the main point of units is to make configuring easier,
requiring byte-exact typing makes them unnecessarily fragile.
- In attempt to preserve maximum range of values for INT64_IS_BUSTED
Marko Kreen [EMAIL PROTECTED] writes:
- In attempt to preserve maximum range of values for INT64_IS_BUSTED
systems, the code is written rather non-obvious way.
I do not personally object a bit to making the units comparisons
case-insensitive (I think it's mainly Peter who wants to be strict
74 matches
Mail list logo
