> 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 no
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 th
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=#
> a) Verbosely spelling out the units in the default config file
> temp_buffers = 16 megabytes
> or
> temp_buffers = 16 milliblocks :-)
> Naive users who favor cut&paste will use the verbose words
> that should leave little room for confusion. Power-users
> who know the short forms fro
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 = 1
>> 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_buffe
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. I
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
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) fr
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. Becau
> 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 t
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
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 Post
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
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, it
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, o
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
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 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 b
"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
> va
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
-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,
"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.
-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 w
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 exam
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 exa
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
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
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:
>
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
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 co
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 order
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 po
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
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 lower
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
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
> > data
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.
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
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 standard
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 restar
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
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
> > >
-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, 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 matt
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 s
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 Kro
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
--
Andre
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
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 M
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 li
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 ,
>
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
>
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
> > mil
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
b
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
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, com
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 un
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 int
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 M
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
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
"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 w
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 a
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 eit
"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 t
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,
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
> t
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
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 t
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 mai
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
> case
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 stric
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
s
74 matches
Mail list logo
