On Tue, Aug 19, 2008 at 9:40 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
>> I'd still like to see us adopt the proposal from some time ago where
>> we stop commenting out the parameters at all, but short of that,
>> hiding options seems about the worst choice
On Tue, Aug 19, 2008 at 10:56 PM, David Fetter <[EMAIL PROTECTED]> wrote:
>>
>> If this isn't critical, and no one is working on it yet, I can see about
>> whittling away at it for 8.4.
>
i'm doing it...
> Looks like there are just 5 of these:
>
> pg_catalog | pg_cursor | SETOF recor
Joshua Drake wrote:
> On Tue, 19 Aug 2008 23:32:34 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > On idea is for postgresql.conf to merely include other files:
> > > include 'sharedmem.conf'
> > > include 'compat.conf'
> > > ...
> >
> > Tha
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > However, the function only does a subtraction with no adjustment for
> > overflow, and considering it returns a signed int, it can't even display
> > the full range of valid values:
>
> Say again? The possible range of ages is only 2
On Tue, Aug 19, 2008 at 10:03:04PM -0400, Robert Treat wrote:
> On Monday 18 August 2008 10:53:51 Bruce Momjian wrote:
> > Tom Lane wrote:
> > > >> Thanks, and while I approve of that TODO, that's not actually the one
> > > >> I was talking about in the email. The one I was talking about was
> > >
On Wed, 20 Aug 2008 00:10:35 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Another option would be to break up the conf like the above but do
> > not include any of them in the main postgresql.conf (which is how I
> > would argue it should be done). Thus if you want to modify logging,
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> However, the function only does a subtraction with no adjustment for
> overflow, and considering it returns a signed int, it can't even display
> the full range of valid values:
Say again? The possible range of ages is only 2 billion.
I see we recommend using the age(xid) function to check for XID
wraparound:
http://www.postgresql.org/docs/8.3/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
However, the function only does a subtraction with no adjustment for
overflow, and considering it returns a signed int, it ca
On Tue, 19 Aug 2008 23:32:34 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > On idea is for postgresql.conf to merely include other files:
> > include 'sharedmem.conf'
> > include 'compat.conf'
> > ...
>
> That would definitely add complexity
Bruce Momjian <[EMAIL PROTECTED]> writes:
> On idea is for postgresql.conf to merely include other files:
> include 'sharedmem.conf'
> include 'compat.conf'
> ...
That would definitely add complexity ... what would it buy in return?
regards, tom lane
--
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I'd still like to see us adopt the proposal from some time ago where
> > we stop commenting out the parameters at all, but short of that,
> > hiding options seems about the worst choice we could make.
>
> Well, there seems to be a very
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>> * values 33-127 are available by centrally managed registration to help
>> avoid conflicts in Postgres projects on pgfoundry
>> * values 128+ are user defined
> One thing to worry about is a confliction of Rmg
Robert Treat <[EMAIL PROTECTED]> writes:
> I'd still like to see us adopt the proposal from some time ago where
> we stop commenting out the parameters at all, but short of that,
> hiding options seems about the worst choice we could make.
Well, there seems to be a very substantial body of opinion
On Tuesday 19 August 2008 14:39:39 Peter Eisentraut wrote:
> On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
> > Well, why not just make a one-eighty and say that the default
> > postgresql.conf is *empty* (except for whatever initdb puts into it)?
>
> Well, my original implementation of GUC had
On Tue, Aug 19, 2008 at 09:50:53PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
> >> FWIW, given that there will probably always be corner cases. I can
> >> see the attraction in Simon's suggestion of providing a way
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Aug 19, 2008 at 10:06:33PM -0400, Robert Treat wrote:
>> Any thoughts on just making it always print that way and getting rid
>> of the GUC? Anyone want to argue they'll be turning this off?
> I can vaguely imagine somebody wanting to debug the
Robert Treat <[EMAIL PROTECTED]> writes:
> On Monday 18 August 2008 10:53:51 Bruce Momjian wrote:
>> TODO updated:
>> * Fix all set-returning system functions so they support a wildcard
>> target list
> If this isn't critical, and no one is working on it yet, I can see about
> whittling away at i
Robert Treat <[EMAIL PROTECTED]> writes:
> On Tuesday 19 August 2008 12:40:11 Tom Lane wrote:
>> I'd also like to propose making debug_pretty_print default to ON.
>> At least for me, the other formatting is 100% unreadable.
> Any thoughts on just making it always print that way and getting rid of
On Tue, Aug 19, 2008 at 10:06:33PM -0400, Robert Treat wrote:
> On Tuesday 19 August 2008 12:40:11 Tom Lane wrote:
> > I'd also like to propose making debug_pretty_print default to ON.
> > At least for me, the other formatting is 100% unreadable.
>
> Any thoughts on just making it always print tha
On Tuesday 19 August 2008 12:40:11 Tom Lane wrote:
> I'd also like to propose making debug_pretty_print default to ON.
> At least for me, the other formatting is 100% unreadable.
>
Any thoughts on just making it always print that way and getting rid of the
GUC? Anyone want to argue they'll be tur
On Monday 18 August 2008 10:53:51 Bruce Momjian wrote:
> Tom Lane wrote:
> > >> Thanks, and while I approve of that TODO, that's not actually the one
> > >> I was talking about in the email. The one I was talking about was
> > >> "change builtin set-returning functions to use OUT parameters so you
Every thread we are concerned in turns into something strange thing that is
almost entirely differnet from the original intention. First thread we
started was with the intention to discuss how we should handle the problem.
Instead of discussion it was trolled into oblivion. Then we thought so what
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
>> FWIW, given that there will probably always be corner cases. I can
>> see the attraction in Simon's suggestion of providing a way to
>> manually issue a system-wide forced plan flush.
> Would th
Simon Riggs <[EMAIL PROTECTED]> wrote:
> I would like to make a simple change to Resource Manager code to
> introduce a plugin that can redefine or extend Rmgrs.
It looks very reasonable to me.
> * values 33-127 are available by centrally managed registration to help
> avoid conflicts in Postgr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Right. And even if it is a bug the question might be "what sort of bug
> is it?" We might well be prepared to take some risks with code stability
> to plug security or data corruption bugs, a lot more than we would for
> other sorts of bugs.
As indee
On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > If there is plan invalidation then you just change called1() to
> > return one more field and that's it - no juggling with C) and D)
> > and generally less things that can go wrong.
>
> That i
Tom Lane wrote:
Also, there are a whole lot more considerations in a backpatch decision
than just "is it a bug". The (estimated) risk of creating new bugs and
the extent to which the patch will change behavior that apps might be
relying on are two big reasons why we might choose not to back-pa
Hannu Krosing <[EMAIL PROTECTED]> writes:
> If there is plan invalidation then you just change called1() to return
> one more field and that's it - no juggling with C) and D) and generally
> less things that can go wrong.
That is a pure flight of fancy. Adjusting a function's API generally
requir
Joshua Drake <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm not sure that I *want* a formal written-down backpatch policy.
> Then we write a formal guideline. It really isn't fair to new developers
> to not have any idea how they are going to be able to get a patch
> appl
On Tue, Aug 19, 2008 at 09:39:39PM +0300, Peter Eisentraut wrote:
> On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
> > Well, why not just make a one-eighty and say that the default
> > postgresql.conf is *empty* (except for whatever initdb puts into it)?
>
> Well, my original implementation of
On Wed, 2008-08-20 at 00:11 +0300, Hannu Krosing wrote:
> On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> >
> > More generally, if we are to try to invalidate on the strength of
> > pg_proc changes, what of other DDL changes? Operators, operator
> > classes, maybe? How about renaming a sch
Hi.
>I made tests compiling both sources (from CVS repository and from HTTP), and
>i got the next results:
>
>1-) MSVS 2005
>*Source from CVS repository: *fatal error U1073: "Don't know how to make
>'libpq-dist.rc'"
>*Source from http (ver. 8.3.3): **Successfully generated*
It can be made
On Tue, Aug 19, 2008 at 07:12:47PM -, Greg Sabino Mullane wrote:
> > I'm really not in favor of having comments in the conf file that
> > try to tell you about stuff you might want to set, much less why.
> > That task properly belongs to some kind of introductory chapter in
> > the SGML docs.
> you have functions
>
> A) caller1() to callerN() which includes call to called1()
>
> B) one of these functions, say callerM() needs one more field returned
> from called1(), so you either write a completely new function
> called1_v2() with one more field and then update callerM() to call
> cal
Dave Page wrote:
> On Tue, Aug 19, 2008 at 10:03 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Hmm, let me suggest providing it as a manpage for postgresql.conf, i.e.,
> >> you run "man postgresql.conf" and it gives you this manpage documenting
> >> ev
On Tue, 19 Aug 2008, Josh Berkus wrote:
Well, that doesn't help unless we either provide a .conf generation tool
(something I favor) or docs somewhere which explain which are the variables
to be the most concerned with instead of making users read through all 218 of
them.
The design for a pg
On Tue, Aug 19, 2008 at 10:03 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Peter Eisentraut wrote:
>>> I can see that argument, but I think we can quite simply solve it if we
>>> provide a plain-text version of the configuration chapter of the
>>> document
On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The actual criterion is not really "new user-visible feature" versus
> > "bug fix". It's more an attempt at measuring how large a potential
> > impact the change has. The patch I saw was introducin
On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The actual criterion is not really "new user-visible feature" versus
> > "bug fix". It's more an attempt at measuring how large a potential
> > impact the change has. The patch I saw was introducin
On Tue, 19 Aug 2008 17:03:48 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> I can see that argument, but I think we can quite simply solve it
> >> if we provide a plain-text version of the configuration chapter of
> >> the do
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I can see that argument, but I think we can quite simply solve it if we
>> provide a plain-text version of the configuration chapter of the
>> documentation.
> Hmm, let me suggest providing it as a manpage for postgresql.con
On Tue, 2008-08-19 at 16:03 -0400, Robert Haas wrote:
> > Another thing I do not understand well is how people are expected to work in
> > 8.3 with a function based API, without hitting Skype problems. I'm having a
>
> All database-driven applications have this problem. Any time you have
> a data
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The actual criterion is not really "new user-visible feature" versus
> "bug fix". It's more an attempt at measuring how large a potential
> impact the change has. The patch I saw was introducing a whole new
> message type to go through the shared inval
Dimitri Fontaine escribió:
> The problem here (at least for me) was to understand why this (yet to be
> reviewed) patch is about implementing a new feature and not about
> bugfixing an existing one. So we're exactly in the fog around the
> informal backpatch policy, and as long as we're able
On Tue, 19 Aug 2008 16:22:43 -0400
Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> A formal policy that's any more detailed than what's in the FAQ today
> is a solution in search of a problem.
Odd that the problem continues to rear its head though isn't it? This
certainly isn't the first time it has
On Tue, 2008-08-19 at 21:26 +0200, Dimitri Fontaine wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Le 19 août 08 à 19:06, Tom Lane a écrit :
> > Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> >> Another thing I do not understand well is how people are expected
> >> to work
On Tue, Aug 19, 2008 at 12:42:29PM -0700, Joshua Drake wrote:
> Generally speaking we adhere to the following guideline for patches.
>* Security fixes are applied to all applicable branches.
>* Bugfixes are applied to all applicable branches
> * Note: A patch that addresses a known li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 19 août 08 à 22:03, Robert Haas a écrit :
All database-driven applications have this problem. Any time you have
a database on the backend and interface code on the front-end, you
need to keep in mind that it won't necessarily be possible to
Peter Eisentraut wrote:
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
Text space is cheap,
I'd offer the alternative theory that anything that is longer than one screen
is overwhelming and unwieldy.
One more benefit of a small file is that it makes it easier to ask someone
"
> Another thing I do not understand well is how people are expected to work in
> 8.3 with a function based API, without hitting Skype problems. I'm having a
All database-driven applications have this problem. Any time you have
a database on the backend and interface code on the front-end, you
nee
On Tue, 19 Aug 2008 15:43:11 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Peter Eisentraut wrote:
> > On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
> > > moving the documentation further away from it is the wrong idea,
> > > especially if it means firing up a web browser to do
On Tue, Aug 19, 2008 at 02:47:13PM -0400, Tom Lane wrote:
> Whether (and how far) to backpatch has always been a best-judgment call
> in the past, and we've gotten along fine with that. I think having a
> formal policy is just likely to lead to even more complaints:
I completely agree with this.
Peter Eisentraut wrote:
> On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
> > moving the documentation further away from it is the wrong idea,
> > especially if it means firing up a web browser to do so.
>
> I can see that argument, but I think we can quite simply solve it if we
> p
On Tue, 19 Aug 2008 14:47:13 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Joshua Drake wrote:
> >> Is our backpatch policy documented? It does not appear to be in
> >> developer FAQ.
>
> > Seems we need to add it.
>
> I'm not sure that I *want* a form
> I'm really not in favor of having comments in the conf file that try to
> tell you about stuff you might want to set, much less why. That task
> properly belongs to some kind of introductory chapter in the SGML docs.
> Novice DBAs are unlikely even to *find* the config file, let alone look
> ins
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
> moving the documentation further away from it is the wrong idea,
> especially if it means firing up a web browser to do so.
I can see that argument, but I think we can quite simply solve it if we
provide a plain-text version of the c
Le 19 août 08 à 20:47, Tom Lane a écrit :
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and how far) to backpatch has always been a best-judgment
call
in the past, and we've gotten along fine with that. I think having a
formal policy is just likely to lead to eve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 19 août 08 à 19:06, Tom Lane a écrit :
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
Another thing I do not understand well is how people are expected
to work in
8.3 with a function based API, without hitting Skype problems.
What we've go
On Tue, 19 Aug 2008 19:12:47 -
"Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
> Ugh, you are heading in the wrong direction. The configuration file
> should be well documented: moving the documentation further away
> from it is the wrong idea, especially if it means firing up a web
> browser
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> I like Josh B's version a lot. It's not perfect (I'd add a URL for
> each config for example), but it's a great start.
Josh B's approach is great until people start making changes that are
unrelated to (or perhaps even contradictory to) his comme
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I'm really not in favor of having comments in the conf file that try to
> tell you about stuff you might want to set, much less why. That task
> properly belongs to some kind of introductory chapter in the SGML docs.
> Novice DBAs are unlikel
Asko Oja escribió:
> > Another thing I do not understand well is how people are expected to work
> in
> > 8.3 with a function based API, without hitting Skype problems.
> People are expected to use same workarounds as Skype is using. For us
> another unneccessary downtime week ago was what set us m
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Joshua Drake wrote:
> >> Is our backpatch policy documented? It does not appear to be in
> >> developer FAQ.
>
> > Seems we need to add it.
>
> I'm not sure that I *want* a formal written-down backpatch policy.
> Whether (and how far
I made tests compiling both sources (from CVS repository and from HTTP), and
i got the next results:
1-) MSVS 2005
*Source from CVS repository: *fatal error U1073: "Don't know how to make
'libpq-dist.rc'"
*Source from http (ver. 8.3.3): **Successfully generated*
2.) Borland 5.5.1
* Sou
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Joshua Drake wrote:
>> Is our backpatch policy documented? It does not appear to be in
>> developer FAQ.
> Seems we need to add it.
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and how far) to backpatch has always been a b
>>> Joshua Drake <[EMAIL PROTECTED]> wrote:
> Is our backpatch policy documented? It does not appear to be in
> developer FAQ.
It's mentioned here:
http://www.postgresql.org/support/versioning
"PostgreSQL minor releases fix only frequently-encountered, security,
and data corruption bugs to
On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
> Well, why not just make a one-eighty and say that the default
> postgresql.conf is *empty* (except for whatever initdb puts into it)?
Well, my original implementation of GUC had an empty default configuration
file, which was later craptaculated
Hannu Krosing <[EMAIL PROTECTED]> writes:
> what about changing (or adding) values "log" and "notice" ?
> debug_print_plan = log;
> debug_print_plan = notice;
> so you could set that on demand ?
Well, we could, but it would break existing habits for not much gain.
Really this proposal is to make d
Joshua Drake wrote:
> On Tue, 19 Aug 2008 14:29:52 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>
> > > Do I think it should be pushed back to 8.3.x; no. It is a feature. I
> > > don't consider the existing behavior a bug. I consider it a
> > > limitation and we don't back patch fixes
On Tue, 2008-08-19 at 12:40 -0400, Tom Lane wrote:
> Back in April we changed EXPLAIN VERBOSE to not dump the internal plan
> tree anymore, on the grounds that non-hackers didn't want that info and
> hackers could get it with debug_print_plan and related variables.
> Well, now that I've tried to do
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Actually, I think maybe not so hard. Attached is a patch that fixes
> this. It's done by keeping the old filename around. When you change the
> path, the stats collector will start writing the new file the next time
> it writes something (which should b
On Tue, 19 Aug 2008 14:29:52 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Do I think it should be pushed back to 8.3.x; no. It is a feature. I
> > don't consider the existing behavior a bug. I consider it a
> > limitation and we don't back patch fixes for limitations.
>
> The bottom
Joshua Drake wrote:
> On Tue, 19 Aug 2008 12:48:06 +0100
> Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> > "Hannu Krosing" <[EMAIL PROTECTED]> writes:
> >
> > > Maybe there should be something in postgreSQL docs that warns users
> > > against using functions in any non-trivial circumstances, as
>
On Tue, Aug 19, 2008 at 06:33:33PM +0100, Simon Riggs wrote:
>
> On Tue, 2008-08-19 at 12:40 -0400, Tom Lane wrote:
> > Back in April we changed EXPLAIN VERBOSE to not dump the internal plan
> > tree anymore, on the grounds that non-hackers didn't want that info and
> > hackers could get it with d
Magnus Hagander wrote:
> Decibel! wrote:
>> On Aug 13, 2008, at 4:12 AM, Magnus Hagander wrote:
>>> Tom Lane wrote:
Decibel! <[EMAIL PROTECTED]> writes:
> I disagree. While we don't guarantee stats are absolutely up-to-date,
> or atomic I don't think that gives license for them to just
> Another thing I do not understand well is how people are expected to work
in
> 8.3 with a function based API, without hitting Skype problems.
People are expected to use same workarounds as Skype is using. For us
another unneccessary downtime week ago was what set us moving/thinking :).
When you u
2008/8/19 Dimitri Fontaine <[EMAIL PROTECTED]>:
> Le mardi 19 août 2008, Tom Lane a écrit :
>> [ shrug... ] You have not found a bug in plan invalidation. You have
>> found omitted functionality --- functionality that was *intentionally*
>> omitted from the 8.3 version.
>
> Thanks a lot for this c
Polite answers lead to polite discussions. Caling other people names lead to
flame wars.
It's perfectly ok for Skype to keep our own build of 8.3 with given patch
and make it available for whoever might want it. At least now there is
almost good enough description why the patch was needed althou it
On Tue, 19 Aug 2008 12:17:46 -0500
"Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> Well, this sure looks scary:
>
> # maintenance_work_mem = 256MB #webserver with 2GB RAM
I would agree. 2GB isn't that much memory as it is and that is a fairly
heft amount of maintenance_work_mem. This isn't the d
On Tue, 19 Aug 2008 13:22:34 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm really not in favor of having comments in the conf file that try
> to tell you about stuff you might want to set, much less why. That
> task properly belongs to some kind of introductory chapter in the
> SGML docs. Novi
On Tue, 2008-08-19 at 12:40 -0400, Tom Lane wrote:
> Back in April we changed EXPLAIN VERBOSE to not dump the internal plan
> tree anymore, on the grounds that non-hackers didn't want that info and
> hackers could get it with debug_print_plan and related variables.
> Well, now that I've tried to d
On Tue, Aug 19, 2008 at 1:17 PM, Kevin Grittner
<[EMAIL PROTECTED]> wrote:
>> Josh Berkus <[EMAIL PROTECTED]> wrote:
> But I'm amazed by this, too:
>
> # max_connections = 700 # web application database
>
> How many CPUs and spindles are you assuming there?
>
> My testing and experience suggest ap
Joshua Drake <[EMAIL PROTECTED]> writes:
> If we move to the above route, we end up in an environment with a
> single source for "official" documentation and we can always point to
> that.
Yeah, the fundamental point here is whether or not postgresql.conf
should be trying to serve as part of our s
>>> Josh Berkus <[EMAIL PROTECTED]> wrote:
> Attached is the postgresql.conf.simple I used in my presentaiton. It
> has an egregious math error in it (see if you can find it) but should
> give you the general idea.
Well, this sure looks scary:
# maintenance_work_mem = 256MB #webserver wi
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Another thing I do not understand well is how people are expected to work in
> 8.3 with a function based API, without hitting Skype problems.
I could understand this level of complaining if this were a new problem
that'd appeared in 8.3. But *every
On Tue, 19 Aug 2008 12:48:20 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Joshua Drake <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Well, why not just make a one-eighty and say that the default
> >> postgresql.conf is *empty* (except for whatever initdb puts into
> >> it
Tom,
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
I've never thought that the current contents were especially useful
as documentation; the kindest thing you can say about 'em is that they
are duplicative of t
Joshua Drake <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Well, why not just make a one-eighty and say that the default
>> postgresql.conf is *empty* (except for whatever initdb puts into it)?
> I guess it would depend on what initdb puts into it.
Per the code:
max_connec
Back in April we changed EXPLAIN VERBOSE to not dump the internal plan
tree anymore, on the grounds that non-hackers didn't want that info and
hackers could get it with debug_print_plan and related variables.
Well, now that I've tried to do some planner development work relying on
debug_print_plan
Le mardi 19 août 2008, Tom Lane a écrit :
> [ shrug... ] You have not found a bug in plan invalidation. You have
> found omitted functionality --- functionality that was *intentionally*
> omitted from the 8.3 version.
Thanks a lot for this clarification, now I understand you viewpoint.
So, the 8
Having recently updated my work machine to Fedora 9, I'm now getting
blessed with all the -Winline warnings that gcc 4.3 likes to emit.
I recall some other folk complaining of that previously. While I could
suppress the switch in a Makefile.custom, I'm wondering whether it's
really doing anything
On Tue, 19 Aug 2008 12:12:16 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Joshua Drake <[EMAIL PROTECTED]> writes:
> > Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > Yes but part of this idea is valid. The fact is the majority of the
> > postgresql.conf parameters don't need to be in there by defa
Joshua Drake <[EMAIL PROTECTED]> writes:
> Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> Using that to include a file that's full of comments anyway (which is
>> all that's left in postgresql.conf at this time, I'm sure) just seems.
>> Well. Sub-optimal.
> Yes but part of this idea is valid. The f
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> - now, we have found a bug in plan invalidation
[ shrug... ] You have not found a bug in plan invalidation. You have
found omitted functionality --- functionality that was *intentionally*
omitted from the 8.3 version.
regard
On Tue, 19 Aug 2008 12:48:06 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Hannu Krosing" <[EMAIL PROTECTED]> writes:
>
> > Maybe there should be something in postgreSQL docs that warns users
> > against using functions in any non-trivial circumstances, as
> > functions are not expected to be
Le mardi 19 août 2008, Tom Lane a écrit :
> For the same reasons that plan invalidation itself was a new feature
> and not a bug fix;
I'm sorry but that doesn't help me a dime to understand current situation. It
could well be just me, but... here's how I see it:
- plan invalidation is a new fe
On Tue, 19 Aug 2008 17:11:49 +0200
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera wrote:
> > Hans-Juergen Schoenig wrote:
> >
> >> alternatively we could use some sort of "#include" mechanism to
> >> split "most important" and "not so important".
> >
> > We already have an "include"
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> I was kinda wondering about something closer to the TOAST model,
where
> a blob is only referenceable from a value that's in a table field;
> and that value encapsulates the "name" of the blob in some way that
> needn't even be user-visible. This'd grea
Alvaro Herrera wrote:
> Hans-Juergen Schoenig wrote:
>
>> alternatively we could use some sort of "#include" mechanism to split
>> "most important" and "not so important".
>
> We already have an "include" mechanism.
Using that to include a file that's full of comments anyway (which is
all that
Hans-Juergen Schoenig wrote:
> alternatively we could use some sort of "#include" mechanism to split
> "most important" and "not so important".
We already have an "include" mechanism.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consul
1 - 100 of 131 matches
Mail list logo
