Fujii Masao writes:
> On Thu, Mar 20, 2014 at 2:34 AM, Jeff Janes wrote:
>> In 9.4dev, if the server is started with effective_cache_size = -1, then it
>> cannot be changed away from that without a restart.
> I think that's a bug. Patch attached.
PGC_S_FILE is at least as bogus as the previous
On Thu, Mar 20, 2014 at 2:34 AM, Jeff Janes wrote:
> In 9.4dev, if the server is started with effective_cache_size = -1, then it
> cannot be changed away from that without a restart. If you change the
> config file and do a reload or pg_reload_conf(), it ignores the change
> without comment in th
In 9.4dev, if the server is started with effective_cache_size = -1, then it
cannot be changed away from that without a restart. If you change the
config file and do a reload or pg_reload_conf(), it ignores the change
without comment in the logs.
If you start the server with a value other than -1,
Magnus Hagander writes:
> So clearly there is an overflow somewhere in the calculation of
> effective_cache_size, most likely from the fact that it's now dynamically
> calculated.
Yeah. Fixed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
To test something unrelated, I set my shared_buffers to 7TB on my laptop
today (no, unfortunately I don't have that much RAM).
That leads to the startup error:
FATAL: -536870912 is outside the valid range for parameter
"effective_cache_size" (-1 .. 2147483647)
So clearly there is an overflow s
Greg,
>
> Well we won't eliminate any problems unless we actually override the
> effective_cache_size setting by clipping it to shared_buffers. I don't
> really see much of a problem doing that. The only case where that
> would annoy someone was if they're intentionally understating
> effective_ca
On Thu, Feb 26, 2009 at 1:33 AM, Joshua D. Drake wrote:
>
> On Wed, 2009-02-25 at 17:04 -0800, Josh Berkus wrote:
>
>> Joshua D. Drake wrote:
>>
>> > I would say no. Although I could see an argument for the default
>> > effective_cache_size always being the same size as shared_buffers.
>>
>> That'
On Wed, 2009-02-25 at 17:04 -0800, Josh Berkus wrote:
> Joshua D. Drake wrote:
> > On Wed, 2009-02-25 at 17:21 -0600, Kevin Grittner wrote:
> >> Should we log a warning at startup when effective_cache_size is less
> >> than shared_buffers?
> >
> > I would say no. Although I could see an argument f
Joshua D. Drake wrote:
On Wed, 2009-02-25 at 17:21 -0600, Kevin Grittner wrote:
Should we log a warning at startup when effective_cache_size is less
than shared_buffers?
I would say no. Although I could see an argument for the default
effective_cache_size always being the same size as shared_b
On Wed, 2009-02-25 at 17:21 -0600, Kevin Grittner wrote:
> Should we log a warning at startup when effective_cache_size is less
> than shared_buffers?
I would say no. Although I could see an argument for the default
effective_cache_size always being the same size as shared_buffers.
Joshua D. Drak
Should we log a warning at startup when effective_cache_size is less
than shared_buffers?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 i
> > 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
Peter Eisentraut <[EMAIL PROTECTED]> 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
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
Benny Amorsen <[EMAIL PROTECTED]> writes:
> "TL" == Tom Lane <[EMAIL PROTECTED]> 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 sho
> "TL" == Tom Lane <[EMAIL PROTECTED]> 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 everyth
"Andrew Hammond" <[EMAIL PROTECTED]> 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.
> G
Benny Amorsen wrote:
> > "TL" == Tom Lane <[EMAIL PROTECTED]> 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, wh
Benny Amorsen wrote:
> > "JCN" == Jim C Nasby <[EMAIL PROTECTED]> 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 area
> "JCN" == Jim C Nasby <[EMAIL PROTECTED]> 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
---(end of broadcast)---
TIP 7: You ca
On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
> > "TL" == Tom Lane <[EMAIL PROTECTED]> 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 p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
> > "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
>
> TL> Anyone against making it case-insensitive, speak now or hold your
> TL> peace.
>
> SI-units are inherently case-sensitive [...
> "TL" == Tom Lane <[EMAIL PROTECTED]> 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.
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> On 12/19/06, Tom Lane <[EMAIL PROTECTED]> 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,
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 <[EMAIL PROTECTED]> wrote:
> >> I think we should just accept the strings case-insensitively, too.
> >
> > While acknowledging Peter's pedantically-correct point
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 insensit
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
On Tue, Dec 19, 2006 at 10:12:34PM +, Gregory Stark wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Magnus Hagander <[EMAIL PROTECTED]> 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
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 sensi
On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:
On 12/19/06, Tom Lane <[EMAIL PROTECTED]> 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 th
On 12/19/06, Tom Lane <[EMAIL PROTECTED]> 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
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
Peter Eisentraut <[EMAIL PROTECTED]> 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 imagin
> 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
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. D
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
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:
> 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
On Tue, 2006-12-19 at 19:16 -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> 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
Peter Eisentraut <[EMAIL PROTECTED]> 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
Gregory Stark wrote:
>
> "Kenneth Marshall" <[EMAIL PROTECTED]> 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
"Kenneth Marshall" <[EMAIL PROTECTED]> 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
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
im
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
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 wi
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/
---
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Magnus Hagander <[EMAIL PROTECTED]> 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. Sh
> > 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.
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 u
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 r
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
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 para
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 w
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 abou
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,
> >
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-insens
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
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 Eisentrau
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 <[EMAIL PROTECTED]> writes:
> > > Oh, you mean MB vs Mb. Man, it had to be that simple :)
> >
> > ISTM we had discussed whether guc.c should accept units string
On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> 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
Magnus Hagander <[EMAIL PROTECTED]> 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?
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 m
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
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.postgres
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
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
h
Quoting Simon Riggs <[EMAIL PROTECTED]>:
On Mon, 2006-07-24 at 22:55 +0200, Peter Eisentraut wrote:
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhocke
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Point taken, but I'm inclined to convert it to an integer anyway,
> because that will make the units support much easier. The variable is
> only used in exactly one place anyway, so making sure the calculation
> works right should be easy.
Casting
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Is it intentional that effective_cache_size is a real (as opposed
> > to integer)?
>
> Yes --- the planner generally does all that stuff in float arithmetic
> to avoid worrying about overflow.
Point taken, but I'm inclined to conve
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Is it intentional that effective_cache_size is a real (as opposed to
> integer)?
Yes --- the planner generally does all that stuff in float arithmetic to
avoid worrying about overflow.
regards, tom lane
-
Peter,
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhockery that had all
planner variables be doubles.
I beleive that it's a real because the oth
On Mon, 2006-07-24 at 22:55 +0200, Peter Eisentraut wrote:
> Is it intentional that effective_cache_size is a real (as opposed to
> integer)? The initial revision of guc.c already has it that way, so it
> was probably blindly adapted from the previous adhockery that had all
> planner variables
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhockery that had all
planner variables be doubles.
--
Peter Eisentraut
http://developer.postgresql.org/~
Manfred Koizar <[EMAIL PROTECTED]> writes:
> The estimator only uses effective_cache_size, it never looks at
> NBuffers. So shouldn't we add
> if (effective_cache_size < NBuffers)
Pretty useless considering that effective_cache_size can be SET on the
fly...
In general, my philosophy has b
The estimator only uses effective_cache_size, it never looks at
NBuffers. So shouldn't we add
if (effective_cache_size < NBuffers)
{
elog(NOTICE, "adjusting effective_cache_size to %d",
NBuffers);
effective_cache_size =
75 matches
Mail list logo
