David E. Wheeler wrote:
On Jun 5, 2008, at 14:47, Greg Smith wrote:
This is why there's the emphasis on preserving comments as they pass
into the GUC structure and back to an output file. This is one of the
implementation details I haven't fully made up my mind on: how to
clearly label
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,
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 around for
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's
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 good as sed'ing
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
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.
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 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 use?
* 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 you
have some
* 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 there was one,
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, throwing
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;
unsigned
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 if you
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-hackers,
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 fairly
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.
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 the
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
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
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
problem is
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 data.
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
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
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
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
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
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
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 using an
* 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 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 makes a
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
-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
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 multiple
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
structure
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 to me later
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
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
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 be trying to
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
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 that
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 already
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
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. Not
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, which
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 from
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
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 be
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 exclusive
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 what settings
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
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 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
very
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
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 included
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 postgres's
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
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
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,
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/strftime.c
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
[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 # automatically set by
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 almost ready is
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're
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 know
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
information for tool
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
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
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 to
70 matches
Mail list logo
