"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Not surprising really. It is a simple adjustment to make and it also is
> easy to spot when its a problem. However it is not trivial to test for
> (in terms of time and effort). I know 10 is wrong and so do you.
Sure. But what is right? I'm afraid
On Fri, 2008-06-06 at 20:19 -0400, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> Actually, the reason it's still 10 is that the effort expended to get it
> changed has been *ZERO*. I keep asking for someone to make some
> measurements, do some benchmarking, anything to make a pla
On Fri, 6 Jun 2008, Tom Lane wrote:
Well, you can't see the default or reset values in pg_settings, only the
current value. However, I fail to see the use of either of those for
a configure wizard.
I'm under the impression that the primary reason to put the default in
there is to make it eas
Greg Smith <[EMAIL PROTECTED]> writes:
> On Fri, 6 Jun 2008, Gregory Stark wrote:
>> "Greg Smith" <[EMAIL PROTECTED]> writes:
>>> 1) Is it worthwhile to expand the information stored in the GUC structure to
>>> make it better capable of supporting machine generation and to provide more
>>> informat
Robert Treat <[EMAIL PROTECTED]> writes:
> There is a saying, something like "The accumulation of annecdotes is not
> data". Well, we seem to have a high bar on what proof we need to actually
> change a default GUC settings. default_statistics_target is a prime example,
> where almost no one i
On Sat, 2008-06-07 at 01:30 +0200, Andreas Pflug wrote:
> Gregory Stark wrote:
> > "Andreas Pflug" <[EMAIL PROTECTED]> writes:
> I think I made my point very clear when stating "not a file, but via
> SQL". Though I'm not a native English speaker, and I'm sure you
> understood. I must assume you'
Gregory Stark wrote:
> "Andreas Pflug" <[EMAIL PROTECTED]> writes:
>
>> I personally wouldn't even think about starting such a wizard, unless I have
>> an
>> idea how to push the result into the database. No, not a file, but via SQL!
>> So
>> your statement you won't react unless a wizard is alm
[EMAIL PROTECTED] (Greg Smith) writes:
> On Fri, 6 Jun 2008, Heikki Linnakangas wrote:
>
>> Or perhaps we should explicitly mark the settings the tool has
>> generated, and comment out:
>>
>> #shared_buffers = 32MB # commented out by wizard on 2008-06-05
>> shared_buffers = 1024MB # automaticall
Robert Treat wrote:
While it would be nice to have a clean merge of the two, it's probably simple enough to just
re-implement the differences into your patch (since yours already compiles on 8.4).
Should be straightforward ... I can do the merge.
As far as naming scheme, I'm not particularly
Joshua D. Drake wrote:
> We got the comment on the docs:
>
> log_filename(string) is misleading, since it really doesn't use a
> strftime pattern, but instead a reimplementation of strftime, in order
> to be cross-platform. There is no documentation on this except to look
> in src/timezone/strftim
Bruce Momjian wrote:
> Magnus has started moving the Developer's FAQ to a wiki. I am thinking
> we should move the main FAQ and the TODO list to a wiki as well if the
> community is in agreement.
Discussion with you and Magnus indicated that you were both committed to
having the TODO on the wiki
On Fri, 6 Jun 2008, Gregory Stark wrote:
"Greg Smith" <[EMAIL PROTECTED]> writes:
1) Is it worthwhile to expand the information stored in the GUC structure to
make it better capable of supporting machine generation and to provide more
information for tool authors via pg_settings? The exact fi
Robert Treat wrote:
On Wednesday 04 June 2008 22:04:54 Greg Smith wrote:
I was just talking to someone today about building a monitoring tool for
this. Not having a clear way to recommend people monitor use of work_mem
and its brother spilled to disk sorts is an issue right now, I'll whack
t
On Thu, 05 Jun 2008 12:53:55 -0700 Ron Mayer wrote:
> Steve Atkins wrote:
> > ... cross-platform (Windows, Linux, Solaris, OS X as a bare
> > minimum)
>
> I wonder how cross-platform the tuning algorithm itself is.
>
> I could also imagine that decisions like "do I let the OS page
> cache, or p
"Greg Smith" <[EMAIL PROTECTED]> writes:
> 1) Is it worthwhile to expand the information stored in the GUC structure to
> make it better capable of supporting machine generation and to provide more
> information for tool authors via pg_settings? The exact fields that should or
> shouldn't be incl
Joshua D. Drake wrote:
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
- If we know better values, why don't we set them by default?
The problem is: better for what?
That is where some 80% solution sample config files come in.
+1.
At work I use 3 templates.
* One for salespeo
On Friday 06 June 2008 14:32:27 Robert Lor wrote:
> Robert Treat wrote:
> > certainly by the time 8.4 ships, these should work with freebsd I'd
> > think. ideally we would need to confirm this by release time, certainly
> > getting a bsd buildfarm member to compile with them would be a start (and
>
Robert Treat wrote:
> One idea I have been kicking around is having every guc have a anchor in the
> website (rahter than anchoring on parameter family). It might be enough to
> just populate the search bot with every guc anchored to family though...
+1 on the anchor per variable.
--
Alvaro
On Fri, 6 Jun 2008, Tom Lane wrote:
I grow weary of this thread.
If we keep it up for, oh, another three years, then maybe you'll be as
weary as I am of struggling with problems in this area. Strinking a
balance between the wants and needs of people who want a fancy GUI tool
for configurin
On Friday 06 June 2008 08:35:00 Peter Eisentraut wrote:
> Am Mittwoch, 4. Juni 2008 schrieb Tom Lane:
> > * Can we present the config options in a more helpful way (this is 99%
> > a documentation problem, not a code problem)?
>
> ack
>
> > * Can we build a "configuration wizard" to tell newbies wh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This seems rather crazy, and you haven't actually given a single
convincing use-case.
One area that I find it useful is where it will be useful is in
ProcArrayEndTransaction where it uses exclus
On Thursday 05 June 2008 15:15:14 Greg Smith wrote:
> (1) is in that proposal but is strictly optional as something to put in
> the configuration file itself. The idea behind (2) is to enable tool
> authors to have an easier way to suggest where to head for more
> information. I'd like for it to
On Fri, 6 Jun 2008, Heikki Linnakangas wrote:
Or perhaps we should explicitly mark the settings the tool has generated, and
comment out:
#shared_buffers = 32MB # commented out by wizard on 2008-06-05
shared_buffers = 1024MB # automatically set by wizard on 2008-06-05
What I would like to
"Andreas Pflug" <[EMAIL PROTECTED]> writes:
> I personally wouldn't even think about starting such a wizard, unless I have
> an
> idea how to push the result into the database. No, not a file, but via SQL! So
> your statement you won't react unless a wizard is almost ready is prohibitive,
> apart
On Jun 6, 2008, at 12:22 PM, Greg Smith wrote:
On Fri, 6 Jun 2008, Peter Eisentraut wrote:
- What settings do "newbies" (or anyone else) typically need to
change?
Please post a list.
- What values would you set those settings to? Please provide a
description
for arriving at a value, whic
On Wednesday 04 June 2008 22:04:54 Greg Smith wrote:
> On Wed, 4 Jun 2008, Aidan Van Dyk wrote:
> > * Are we always spilling small amounts of data to disk for sorting? A
> > a small work_mem increase might help...
>
> I was just talking to someone today about building a monitoring tool for
> this
On Fri, 6 Jun 2008, Peter Eisentraut wrote:
- What settings do "newbies" (or anyone else) typically need to change?
Please post a list.
- What values would you set those settings to? Please provide a description
for arriving at a value, which can later be transformed into code. Note that
in so
Robert Lor <[EMAIL PROTECTED]> writes:
> As soon as the DTrace port is working on FreeBSD, I will confirm that
> the probes are working properly, and it's definitely a good idea to get
> a buildfarm machine building with --enable-dtrace.
I'm pretty certain one of the OS X build critters is alrea
On Monday 02 June 2008 10:12:06 Tom Lane wrote:
> I have no objection to providing alternative ways to edit the
> configuration data, but the primary source of the settings is
> going to continue to be an editable text file. Any proposals for
> alternatives-to-a-text-editor have to work within tha
Tom Lane wrote:
I grow weary of this thread. I will say it once more: I do not believe
for one instant that the current formatting of postgresql.conf is the
major impediment, or even a noticeable impediment, to producing a useful
configuration wizard. If you wish to prove otherwise, provide a
c
On Fri, 2008-06-06 at 12:39 -0400, Tom Lane wrote:
> "Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> > New Lock Mode Proposed: LW_EX_OWNER (input on better name will be
> > appreciated).
>
> This seems rather crazy, and you haven't actually given a single
> convincing use-case. Shouldn't you b
Gregory Stark wrote:
Text config files are NOT friendly for beginner and mediocre users. IMHO the
current restriction on GUC changes is a major obstacle towards pgsql tuning
tools, e.g. written as a Google SoC project. Graphic tools aren't too popular
at pgsql-hackers, but please contemplate a
Robert Treat wrote:
certainly by the time 8.4 ships, these should work with freebsd I'd think.
ideally we would need to confirm this by release time, certainly getting a
bsd buildfarm member to compile with them would be a start (and very unlikely
to cause issues)
As soon as the DTrace por
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
>>> New Lock Mode Proposed: LW_EX_OWNER (input on better name will be
>>> appreciated).
> We do something like this in the sinval code -- see SIGetDataEntry.
Yeah, that analogy occurred
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This seems rather crazy, and you haven't actually given a single
>> convincing use-case.
> One area that I find it useful is where it will be useful is in
> ProcArrayEndTransaction where it uses exclusive to update proc array
>
Tom Lane wrote:
> "Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> > New Lock Mode Proposed: LW_EX_OWNER (input on better name will be
> > appreciated).
>
> This seems rather crazy, and you haven't actually given a single
> convincing use-case. Shouldn't you be trying to break down a lock
> into
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
New Lock Mode Proposed: LW_EX_OWNER (input on better name will be
appreciated).
This seems rather crazy, and you haven't actually given a single
convincing use-case. Shouldn't you be trying to break down a lock
into mult
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Bugger... Now we only need to make postgresql check postmaster.conf
> into git everytime it makes a change...
Been there, wrote that. (for postgresql.conf anyway).
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200806061351
h
This report:
http://archives.postgresql.org/pgsql-general/2008-06/msg00208.php
shows that there is a nasty oversight in my patch of awhile back:
http://archives.postgresql.org/pgsql-committers/2008-01/msg00081.php
which might cause pg_dump output to fail to reload. This is a
regression compared to
On Fri, 2008-06-06 at 13:07 -0400, Aidan Van Dyk wrote:
> * David E. Wheeler <[EMAIL PROTECTED]> [080606 12:22]:
>
> > I guess that could be a feature. Personally, I use a vcs system for
> > that.
>
> Bugger... Now we only need to make postgresql check postmaster.conf
> into git everytime it
* David E. Wheeler <[EMAIL PROTECTED]> [080606 12:22]:
> I guess that could be a feature. Personally, I use a vcs system for
> that.
Bugger... Now we only need to make postgresql check postmaster.conf
into git everytime it makes a change...
;-)
--
Aidan Van Dyk
On Saturday 31 May 2008 17:34:27 David E. Wheeler wrote:
> On May 31, 2008, at 12:36, Gregory Stark wrote:
> > What this sounds like is a sly way to try to get rid of
> > postgresql.conf
> > entirely and replace it with parameters stored in the database so
> > admins would
> > adjust the parameters
On Wednesday 04 June 2008 15:48:47 Andrew Dunstan wrote:
> simply remove all the comment lines from your
> config file.
+1. That would clear up a lot of confusion on it's own.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> New Lock Mode Proposed: LW_EX_OWNER (input on better name will be
> appreciated).
This seems rather crazy, and you haven't actually given a single
convincing use-case. Shouldn't you be trying to break down a lock
into multiple locks instead of inv
On Jun 6, 2008, at 01:50, Andreas Pflug wrote:
Two heretical questions:
Do we need user generated comments at all?
I can't remember ever having used any comment in postgresql.conf.
That's a valid point. I've used comments to note by whom and when when
a setting was changed.
Why do so many
On Jun 5, 2008, at 23:08, Heikki Linnakangas wrote:
What comments do we consider machine-generated? Just the ones used
to comment out settings, like
#shared_buffers = 32MB
or something else?
Those and documentation comments.
If the automatic tool lets alone all other kind of comments, I t
Currently there are two modes of LWLock : SHARED and EXCLUSIVE
Mostly you need to have EXCLUSIVE lock mode to make any changes, add,
delete and SHARED if you are just reading it. Multiple backends can
grab SHARED mode simultaneously while only one Backend can grab
EXCLUSIVE at a time. There a
Peter Eisentraut wrote:
Am Freitag, 6. Juni 2008 schrieb Joshua D. Drake:
That is where some 80% solution sample config files come in.
Considering that writing a sample configuration file is trivial, yet I haven't
seen a single one posted in the six or more years of GUC, I have no faith in
t
On Saturday 17 May 2008 22:33:01 Robert Lor wrote:
> (Resending since it didn't work the first time. Not sure if attaching a
> tar file was the culprit.)
>
> I'd like to propose adding the following probes (some of which came from
> Simon) to 8.4.
>
+1
> I think these probe provide very useful da
On Fri, Jun 6, 2008 at 10:35 AM, Bjorn Munch <[EMAIL PROTECTED]> wrote:
> Have you tried with Studio 12? I have a vague recollection that it
> might treat this differently (in order words, accept it), but I may be
> wrong...
It may work, but it's still unportable code. Correcting the root
proble
Am Freitag, 6. Juni 2008 schrieb Joshua D. Drake:
> That is where some 80% solution sample config files come in.
Considering that writing a sample configuration file is trivial, yet I haven't
seen a single one posted in the six or more years of GUC, I have no faith in
this plan until I actually
Peter Eisentraut wrote:
Am Freitag, 6. Juni 2008 schrieb Tom Lane:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
- If we know better values, why don't we set them by default?
The problem is: better for what? In particular, I'm uncomfortable with
any changes in the direction of trying to make P
Am Freitag, 6. Juni 2008 schrieb Tom Lane:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > - If we know better values, why don't we set them by default?
>
> The problem is: better for what? In particular, I'm uncomfortable with
> any changes in the direction of trying to make Postgres take over
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
- If we know better values, why don't we set them by default?
The problem is: better for what? In particular, I'm uncomfortable with
any changes in the direction of trying to make Postgres take over the
entire machine by default. I
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> - If we know better values, why don't we set them by default?
The problem is: better for what? In particular, I'm uncomfortable with
any changes in the direction of trying to make Postgres take over the
entire machine by default. I'd want some fairl
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Text config files are NOT friendly for beginner and mediocre users. IMHO
> the current restriction on GUC changes is a major obstacle towards pgsql
> tuning tools, e.g. written as a Google SoC project. Graphic tools aren't
> too popular at pgsql-hacker
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> And note that one of the major advances in X.org over XFree86 was that all
> the
> useless garbage was removed from the configuration file, so that the final
> and usable configuration fits on one screen, and you can even write it from
> memory
On 05/06 10.44, Mayuresh Nirhali wrote:
> Sun Studio does not like array declarations with null as dimenstion.
> So, In pipe.c we have,
>
> typedef struct
> {
>LWLockId shmem_lock;
>pipe *pipes;
>alert_event *events;
>alert_lock *locks;
>size_t size;
>
"Andreas Pflug" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> So all you have is our existing file except with an additional layer of
>> quoting to deal with, a useless SET keyword to annoy users, and a file that
>> you need a bison parser
>
> Don't you think that's a little over the top,
* Peter Eisentraut <[EMAIL PROTECTED]> [080606 08:25]:
> Am Mittwoch, 4. Juni 2008 schrieb Aidan Van Dyk:
> > > When reading this thread, I'm wondering if anybody ever saw a config
> > > file for a complex software product that was easily editable and
> > > understandable. I don't know one. If ther
* Andreas Pflug <[EMAIL PROTECTED]> [080606 04:50]:
> David E. Wheeler wrote:
> >
> >How about a simple rule, such as that machine-generated comments start
> >with "##", while user comments start with just "#"? I think that I've
> >seen such a rule used before. At any rate, I think that, unless y
Am Donnerstag, 5. Juni 2008 schrieb Tom Lane:
> How far could we get with the answers to just three questions:
>
> * How many concurrent queries do you expect to have?
>
> * How much RAM space are you willing to let Postgres use?
>
> * How much "overhead" disk space are you willing to let Postgres
Am Mittwoch, 4. Juni 2008 schrieb Tom Lane:
> * Can we present the config options in a more helpful way (this is 99%
> a documentation problem, not a code problem)?
ack
> * Can we build a "configuration wizard" to tell newbies what settings
> they need to tweak?
Some questions to clarify this:
Am Mittwoch, 4. Juni 2008 schrieb Aidan Van Dyk:
> > When reading this thread, I'm wondering if anybody ever saw a config
> > file for a complex software product that was easily editable and
> > understandable. I don't know one. If there was one, it'd be nice to know
> > it so we can learn from it.
Gregory Stark wrote:
So all you have is our existing file except with an additional layer of
quoting to deal with, a useless SET keyword to annoy users, and a file that
you need a bison parser
Don't you think that's a little over the top, throwing bison at the
simple task to extend postgresql.c
"Andreas Pflug" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Andreas Pflug" <[EMAIL PROTECTED]> writes:
>>
>>> Why do so many people here insist on editing postgresql.conf as primary
>>> means
>>> of changing config params?
>>> Isn't a psql -c "SET foo=bar; MAKE PERSISTENT" just as
Gregory Stark wrote:
"Andreas Pflug" <[EMAIL PROTECTED]> writes:
Why do so many people here insist on editing postgresql.conf as primary means
of changing config params?
Isn't a psql -c "SET foo=bar; MAKE PERSISTENT" just as good as sed'ing
postgresql.conf or doing it manually?
no, it
"Andreas Pflug" <[EMAIL PROTECTED]> writes:
> Why do so many people here insist on editing postgresql.conf as primary means
> of changing config params?
> Isn't a psql -c "SET foo=bar; MAKE PERSISTENT" just as good as sed'ing
> postgresql.conf or doing it manually?
no, it's awful.
> Looking arou
David E. Wheeler wrote:
How about a simple rule, such as that machine-generated comments start
with "##", while user comments start with just "#"? I think that I've
seen such a rule used before. At any rate, I think that, unless you
have some sort of line marker for machine-generated comments
69 matches
Mail list logo
