On 9/26/14, 3:22 PM, Tom Lane wrote:
We could alternatively try to split up these cases into multiple GUCs,
which I guess is what you're imagining as a multi-year battle.
No, I was just pointing out that even the cleanest major refactoring
possible here is going to result in broken config
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost sfr...@snowman.net wrote:
* Gregory Smith (gregsmithpg...@gmail.com) wrote:
On 9/25/14, 2:02 PM, Peter Eisentraut wrote:
But having the same parameter setting mean different things in
different
On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost sfr...@snowman.net wrote:
* Gregory Smith (gregsmithpg...@gmail.com) wrote:
On 9/25/14, 2:02 PM, Peter Eisentraut wrote:
But having the same parameter setting mean different things in
different versions is the path to complete madness.
Could we
On Fri, Sep 26, 2014 at 10:58 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost sfr...@snowman.net wrote:
* Gregory Smith (gregsmithpg...@gmail.com) wrote:
On 9/25/14, 2:02 PM, Peter Eisentraut wrote:
But
Robert Haas robertmh...@gmail.com writes:
If we want the narrowest possible fix for this, I think it's complain
if a non-zero value would round to zero. That fixes the original
complaint and changes absolutely nothing else. But I think that's
kind of wussy. Yeah, rounding 29 seconds down to
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas robertmh...@gmail.com writes:
If we want the narrowest possible fix for this, I think it's complain
if a non-zero value would round to zero. That fixes the original
complaint and changes absolutely nothing else. But I think that's
On 09/26/2014 10:27 AM, Stephen Frost wrote:
I don't think anyone is argueing that we should do away with the
rounding rules entirely, only that we should a) require units to be
specified, and b) error if the value specified is below '1 unit', but
still non-zero, as it would then be rounded to
* Josh Berkus (j...@agliodbs.com) wrote:
On 09/26/2014 10:27 AM, Stephen Frost wrote:
I don't think anyone is argueing that we should do away with the
rounding rules entirely, only that we should a) require units to be
specified, and b) error if the value specified is below '1 unit', but
On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If we want the narrowest possible fix for this, I think it's complain
if a non-zero value would round to zero. That fixes the original
complaint and changes absolutely nothing
David Johnston david.g.johns...@gmail.com writes:
On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I apparently have got to make this point one more time: if the user
cares about the difference between 30sec and 1min, then we erred in
designing the GUC in question; it should
On Fri, Sep 26, 2014 at 2:02 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If we want the narrowest possible fix for this, I think it's complain
if a non-zero value would round to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I've been thinking more about this, and I think I'm about ready to
change my position on it: why shouldn't we error out if the value
is too small? If we believe that a GUC's unit is reasonably chosen,
then it's not sensible to try to set the value to
Stephen Frost sfr...@snowman.net writes:
Agreed- they're independent considerations and the original concern was
about the nonzero-to-zero issue, so I'd suggest we address that first,
though in doing so we will need to consider what *actual* min values we
should have for some cases which
On Fri, Sep 26, 2014 at 2:27 PM, Stephen Frost sfr...@snowman.net wrote:
Agreed- they're independent considerations and the original concern was
about the nonzero-to-zero issue, so I'd suggest we address that first,
though in doing so we will need to consider what *actual* min values we
David,
* David Johnston (david.g.johns...@gmail.com) wrote:
This is 9.5 material because 1) it isn't all that critical and, 2) we DO
NOT want a system to not come up because of a GUC paring error after a
minor-release update.
Agreed.
I don't get where we need to do anything else besides
On Fri, Sep 26, 2014 at 2:39 PM, Stephen Frost [via PostgreSQL]
ml-node+s1045698n5820714...@n5.nabble.com wrote:
David,
* David Johnston ([hidden email]
http://user/SendEmail.jtp?type=nodenode=5820714i=0) wrote:
This is 9.5 material because 1) it isn't all that critical and, 2) we
DO
On 09/26/2014 11:17 AM, Tom Lane wrote:
So I'm coming around to the idea that throw an error if a nonzero
input would round (or truncate) to zero is a reasonable solution.
I think it'd be even more reasonable if we also fixed the rounding
rule to be round to nearest, but the two changes can be
On 9/26/14, 2:17 PM, Tom Lane wrote:
Well, ok, let's allow zero as a special case, but it has to be written
as 0 not something else. If you try to set a positive value then we
should act as though the min_val is 1 unit. So I'm coming around to
the idea that throw an error if a nonzero input
On 9/26/14, 2:34 PM, David Johnston wrote:
I don't get where we need to do anything else besides that...the
whole actual min values comment is unclear to me.
If you look at pg_settings, there is a minimum value exposed there as
min_val. For some of these parameters, that number would
Gregory Smith gregsmithpg...@gmail.com writes:
On 9/26/14, 2:34 PM, David Johnston wrote:
â I don't get where we need to do anything else besides that...the
whole actual min values comment is unclear to me.
If you look at pg_settings, there is a minimum value exposed there as
min_val.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
There are others where min_val is -1 for the same reason, where
functionally the minimum is really 0. Some of us would like to see
min_val reflect the useful minimum, period, and move all these special
case ones out of there. That is a multi-year
Tom Lane wrote:
The impression I had was that Stephen was thinking of actually setting
min_val to 1 (or whatever) and handling zero or -1 in some out-of-band
fashion, perhaps by adding GUC flag bits showing those as allowable
special cases. I'm not sure how we would display such a state of
On Friday, September 26, 2014, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Tom Lane wrote:
The impression I had was that Stephen was thinking of actually setting
min_val to 1 (or whatever) and handling zero or -1 in some out-of-band
fashion, perhaps by adding GUC flag bits showing
David Johnston wrote:
On Friday, September 26, 2014, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Tom Lane wrote:
The impression I had was that Stephen was thinking of actually setting
min_val to 1 (or whatever) and handling zero or -1 in some out-of-band
fashion, perhaps by
On 9/26/14, 2:50 PM, David G Johnston wrote:
Like I said I just want to fix the bug and call it a day :)
I'm afraid you've come to the wrong project and mailing list for *that*.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Friday, September 26, 2014, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
David Johnston wrote:
On Friday, September 26, 2014, Alvaro Herrera alvhe...@2ndquadrant.com
javascript:;
wrote:
Tom Lane wrote:
The impression I had was that Stephen was thinking of actually
setting
On 9/25/14, 1:41 AM, David Johnston wrote:
If the error message is written correctly most people upon seeing the
error will simply fix their configuration and move on - regardless of
whether they were proactive in doing so having read the release notes.
The important part to realize here is
On Thursday, September 25, 2014, Gregory Smith gregsmithpg...@gmail.com
wrote:
On 9/25/14, 1:41 AM, David Johnston wrote:
If the error message is written correctly most people upon seeing the
error will simply fix their configuration and move on - regardless of
whether they were proactive in
On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
TBH I've also been wondering whether any of these proposed cures are
better than the disease.
I couldn't agree more. There's something to be said for just leaving
this alone.
The changes that can be argued to make the
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
TBH I've also been wondering whether any of these proposed cures are
better than the disease.
I couldn't agree more. There's something to be said for just leaving
this alone.
On 9/25/14 11:03 AM, Robert Haas wrote:
I couldn't agree more. There's something to be said for just leaving
this alone.
I agree.
potentitally draw complaints. But I also agree with his last one - of
those three possible complaints, I certainly prefer I had to fix my
configuration file
On 9/25/14, 2:02 PM, Peter Eisentraut wrote:
But having the same parameter setting mean different things in
different versions is the path to complete madness.
Could we go so far as to remove support for unitless time settings
eventually? The fact that people are setting raw numbers in the
* Gregory Smith (gregsmithpg...@gmail.com) wrote:
On 9/25/14, 2:02 PM, Peter Eisentraut wrote:
But having the same parameter setting mean different things in
different versions is the path to complete madness.
Could we go so far as to remove support for unitless time settings
eventually?
On 9/23/14 11:55 PM, Gregory Smith wrote:
Right now there are people out there who have configurations that look
like this:
log_rotation_age=60
In order to get hourly rotation. These users will suffer some trauma
should they upgrade to a version where this parameter now means a new
log
On 9/24/14, 6:45 PM, Peter Eisentraut wrote:
But then this proposal is just one of several others that break backward
compatibility, and does so in a more or less silent way. Then we might
as well pick another approach that gets closer to the root of the problem.
I was responding to some
Gregory Smith gregsmithpg...@gmail.com writes:
I don't see any agreement on the real root of a problem here yet. That
makes gauging whether any smaller change leads that way or not fuzzy. I
personally would be fine doing nothing right now, instead waiting until
that's charted
On Thu, Sep 25, 2014 at 12:11 AM, Gregory Smith gregsmithpg...@gmail.com
wrote:
On 9/24/14, 6:45 PM, Peter Eisentraut wrote:
But then this proposal is just one of several others that break backward
compatibility, and does so in a more or less silent way. Then we might
as well pick another
On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Gregory Smith gregsmithpg...@gmail.com writes:
I don't see any agreement on the real root of a problem here yet. That
makes gauging whether any smaller change leads that way or not fuzzy. I
personally would be fine doing
David Johnston david.g.johns...@gmail.com writes:
On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
TBH I've also been wondering whether any of these proposed cures are
better than the disease. The changes that can be argued to make the
behavior more sane are also ones that
On Thu, Sep 25, 2014 at 1:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston david.g.johns...@gmail.com writes:
On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
TBH I've also been wondering whether any of these proposed cures are
better than the disease. The
On Tue, Sep 23, 2014 at 1:23 AM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
To clarify- we'll simply swap from (essentially) floor() to ceil() for
handling all GUC_with_unit to internal_unit conversions, document
Robert Haas robertmh...@gmail.com writes:
Three people have voted for making it an *error* to supply a value
that needs to be rounded, instead of changing the rounding behavior.
Votes or no votes, that's a horrible idea; it breaks the design goal
that users shouldn't need to remember the
On Tue, Sep 23, 2014 at 10:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Three people have voted for making it an *error* to supply a value
that needs to be rounded, instead of changing the rounding behavior.
Votes or no votes, that's a horrible idea; it
On 09/23/2014 10:29 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Three people have voted for making it an *error* to supply a value
that needs to be rounded, instead of changing the rounding behavior.
Votes or no votes, that's a horrible idea; it breaks the design goal
that
On Tue, Sep 23, 2014 at 1:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston david.g.johns...@gmail.com writes:
My original concern was things that are rounded to zero now will not be
in
9.5 if the non-error solution is chosen. The risk profile is extremely
small but it is not
On 09/23/2014 06:23 PM, Andrew Dunstan wrote:
On 09/23/2014 10:29 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Three people have voted for making it an *error* to supply a value
that needs to be rounded, instead of changing the rounding behavior.
Votes or no votes, that's a
Fwiw I agree with TL2. The simplest, least surprising behaviour to explain
to users is to say we round to nearest and if that means we rounded to zero
(or another special value) we throw an error. We could list the minimum
value in pg_settings and maybe in documentation.
--
greg
On Tue, Sep 23, 2014 at 3:05 PM, Greg Stark st...@mit.edu wrote:
Fwiw I agree with TL2. The simplest, least surprising behaviour to explain
to users is to say we round to nearest and if that means we rounded to zero
(or another special value) we throw an error. We could list the minimum
value
On 9/23/14 10:29 AM, Tom Lane wrote:
Votes or no votes, that's a horrible idea; it breaks the design goal
that users shouldn't need to remember the precise unit size when making
postgresql.conf entries.
I think this is not historically correct.
The original motivation was that you had to
On 9/23/14 1:13 AM, Stephen Frost wrote:
To clarify- we'll simply swap from (essentially) floor() to ceil() for
handling all GUC_with_unit to internal_unit conversions, document that,
and note it in the release notes as a possible behavior change and move
on.
That'll probably work, as long as
Peter Eisentraut pete...@gmx.net writes:
On 9/23/14 10:29 AM, Tom Lane wrote:
Votes or no votes, that's a horrible idea; it breaks the design goal
that users shouldn't need to remember the precise unit size when making
postgresql.conf entries.
I think this is not historically correct.
The
On 9/23/14, 1:21 AM, David Johnston wrote:
This patch should fix the round-to-zero issue. If someone wants to
get rid of zero as a special case let them supply a separate patch for
that improvement.
I am going to wander into this fresh after just reading everything once
(but with more than
On Tue, Sep 23, 2014 at 10:11 PM, Gregory Smith gregsmithpg...@gmail.com
wrote:
On 9/23/14, 1:21 AM, David Johnston wrote:
This patch should fix the round-to-zero issue. If someone wants to get
rid of zero as a special case let them supply a separate patch for that
improvement.
I am
On 9/23/14, 10:52 PM, David Johnston wrote:
Given the following why not just pick ms for log_rotation_age now?
Right now there are people out there who have configurations that look
like this:
log_rotation_age=60
In order to get hourly rotation. These users will suffer some trauma
Tomonari,
* Tomonari Katsumata (t.katsumata1...@gmail.com) wrote:
I'm thinking about a method which users get quick awareness it.
Now, it's okay not to change current behavior except non-zero value yields
a zero. A zero rounded down from non-zero gets an error.
I attached new patch.
This
Stephen Frost sfr...@snowman.net writes:
* Tomonari Katsumata (t.katsumata1...@gmail.com) wrote:
I'm thinking about a method which users get quick awareness it.
Now, it's okay not to change current behavior except non-zero value yields
a zero. A zero rounded down from non-zero gets an error.
Hey Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Tomonari Katsumata (t.katsumata1...@gmail.com) wrote:
I'm thinking about a method which users get quick awareness it.
Now, it's okay not to change current behavior except non-zero value yields
a
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
This argument doesn't say anything much about which way to round for
values that are fractional but larger than the unit size. I'd probably
prefer a round away from zero behavior since that seems to be the most
Tom Lane-2 wrote
The case where this argument falls down is for special values, such as
where zero means something quite different from the smallest nonzero
value. Peter suggested upthread that we should redefine any GUC values
for which that is true, but (a) I think that loses on backwards
David G Johnston david.g.johns...@gmail.com writes:
Can you either change your mind back to this opinion you held last month or
commit something you find acceptable - its not like anyone would revert
something you commit... :)
Hey, am I not allowed to change my mind :-) ?
Seriously though,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Here's another proposal- how about we support a 'minimum-if-not-zero'
option for GUCs more generally, and then throw an error if the user sets
the value to a value below that minimum unless they explicitly use zero
(to indicate whatever the special
Stephen Frost sfr...@snowman.net writes:
To clarify- we'll simply swap from (essentially) floor() to ceil() for
handling all GUC_with_unit to internal_unit conversions, document that,
and note it in the release notes as a possible behavior change and move
on.
Worksforme.
On Tuesday, September 23, 2014, Tom Lane t...@sss.pgh.pa.us wrote:
David G Johnston david.g.johns...@gmail.com javascript:; writes:
Can you either change your mind back to this opinion you held last month
or
commit something you find acceptable - its not like anyone would revert
something
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
To clarify- we'll simply swap from (essentially) floor() to ceil() for
handling all GUC_with_unit to internal_unit conversions, document that,
and note it in the release notes as a possible behavior change and
David Johnston david.g.johns...@gmail.com writes:
My original concern was things that are rounded to zero now will not be in
9.5 if the non-error solution is chosen. The risk profile is extremely
small but it is not theoretically zero.
This is exactly the position I was characterizing as an
Hi,
I'm sorry for slow reaction.
I don't care whether rounding up or down it, although this title has
'rounding up'.
(I just only come up with it. I'm sorry for my imprudence)
I'm thinking about a method which users get quick awareness it.
Now, it's okay not to change current behavior except
On Sat, Aug 23, 2014 at 6:39 PM, Greg Stark st...@mit.edu wrote:
On Sat, Aug 23, 2014 at 9:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ah. Okay, but then what's wrong with the original proposal of use ceil()
instead of floor()? Basically I think the idea of treating fractions
less than one
On 2014-08-26 16:16:32 -0400, Robert Haas wrote:
On Sat, Aug 23, 2014 at 6:39 PM, Greg Stark st...@mit.edu wrote:
On Sat, Aug 23, 2014 at 9:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ah. Okay, but then what's wrong with the original proposal of use ceil()
instead of floor()? Basically I
On 8/23/14 6:39 PM, Greg Stark wrote:
Or make it an error to specify a value that rounds to 0 but isn't 0.
That's what I would prefer.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 8/26/14 4:22 PM, Andres Freund wrote:
Is the whole topic actually practically relevant?
It's clearly not all that important, or otherwise we'd have heard about
before now.
I suppose someone could do something like
wal_receiver_status_interval = 10ms
and end up silently turning the whole
Robert Haas robertmh...@gmail.com writes:
I liked David Johnston's even stronger suggestion upthread: make it an
error to specify a value requires rounding of any kind. In other
words, if the minimum granularity is 1 minute, you can specify that as
60 seconds instead, but if you write 59
Tom Lane-2 wrote
Robert Haas lt;
robertmhaas@
gt; writes:
I liked David Johnston's even stronger suggestion upthread: make it an
error to specify a value requires rounding of any kind. In other
words, if the minimum granularity is 1 minute, you can specify that as
60 seconds instead, but
Tomonari Katsumata t.katsumata1...@gmail.com writes:
This patch rounds up the value when only it's less than required unit.
..
Although my original complaint is fixed, I'm worried about this change will
make users confusing.
Indeed. I have not understood why you are insisting on round up
Tom Lane-2 wrote
Tomonari Katsumata lt;
t.katsumata1122@
gt; writes:
This patch rounds up the value when only it's less than required unit.
..
Although my original complaint is fixed, I'm worried about this change
will
make users confusing.
Indeed. I have not understood why you are
David G Johnston david.g.johns...@gmail.com writes:
Tom Lane-2 wrote
Indeed. I have not understood why you are insisting on round up
semantics. Wouldn't it make more sense for the behavior to be round to
nearest? That would get rid of any worries about treating zero
specially.
Wasn't the
On Sat, Aug 23, 2014 at 9:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ah. Okay, but then what's wrong with the original proposal of use ceil()
instead of floor()? Basically I think the idea of treating fractions
less than one differently from fractions greater than one is bogus; nobody
will
Tom Lane-2 wrote
David G Johnston lt;
david.g.johnston@
gt; writes:
Tom Lane-2 wrote
Indeed. I have not understood why you are insisting on round up
semantics. Wouldn't it make more sense for the behavior to be round to
nearest? That would get rid of any worries about treating zero
Thank you for the comments.
It was a bug in my patch as another developer says.
I've not considered about the value 'zero', sorry.
I attached new patch.
This patch rounds up the value when only it's less than required unit.
Like below.
(unit: min)
0-0
0s-0
10s-1
70s-1
Although my original
On 07/10/2014 09:52 AM, Tomonari Katsumata wrote:
Hi,
Several couple weeks ago, I posted a mail to pgsql-doc.
http://www.postgresql.org/message-id/53992ff8.2060...@po.ntts.co.jp
In this thread, I concluded that it's better to
round up the value which is less than its unit.
Current behavior
Heikki Linnakangas hlinnakan...@vmware.com writes:
The patch also rounds a zero up to one. A naked zero with no unit is not
affected, but e.g if you have log_rotation_age=0s, it will not disable
the feature as you might expect, but set it to 1 minute. Should we do
something about that?
On 8/21/14 11:16 AM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
The patch also rounds a zero up to one. A naked zero with no unit is not
affected, but e.g if you have log_rotation_age=0s, it will not disable
the feature as you might expect, but set it to 1 minute.
Peter Eisentraut-2 wrote
On 8/21/14 11:16 AM, Tom Lane wrote:
Heikki Linnakangas lt;
hlinnakangas@
gt; writes:
The patch also rounds a zero up to one. A naked zero with no unit is not
affected, but e.g if you have log_rotation_age=0s, it will not disable
the feature as you might expect,
Hi Robert,
Thank you for checking this!
I've added it to commitfest.
https://commitfest.postgresql.org/action/patch_view?id=1507
regards,
Tomonari Katsumata
2014-07-12 6:07 GMT+09:00 Robert Haas robertmh...@gmail.com:
On Thu, Jul 10, 2014 at 2:52 AM, Tomonari Katsumata
On Thu, Jul 10, 2014 at 2:52 AM, Tomonari Katsumata
katsumata.tomon...@po.ntts.co.jp wrote:
Several couple weeks ago, I posted a mail to pgsql-doc.
http://www.postgresql.org/message-id/53992ff8.2060...@po.ntts.co.jp
In this thread, I concluded that it's better to
round up the value which is
84 matches
Mail list logo
