Would it help to have two lines in the config file for each setting, one
with the default (comment) and one with the actual setting? So for
example, the postgresql.conf would ship with something like this:
#tcpip_socket = false #default
tcpip_socket = false
Even better, have a
On Jun 16, 2004, at 1:05 PM, Christopher Kings-Lynne wrote:
The proposal is to remove the comments from postgresql.conf (like
Apache) so all entries will be active. The downside is that it will
not
be possible to determine which values were modified from their
defaults.
One thing that truly
This seems like a nice idea -
It might even be worth targeting a couple pf specific ranges - e.g :
machines with 1G RAM and 4G RAM ( medium are large come to mind, I
know it's a bit like that other database product we know of but
that doesn't mean it's necessarily bad!)
Mark
Christopher
Oh dear, a lot of typos here, hopefully still decipherable... apologies.
Mark
Mark Kirkwood wrote:
This seems like a nice idea -
It might even be worth targeting a couple pf specific ranges - e.g :
machines with 1G RAM and 4G RAM ( medium are large come to mind,
I know it's a bit like that
Christopher Kings-Lynne wrote:
The proposal is to remove the comments from postgresql.conf (like
Apache) so all entries will be active. The downside is that it will not
be possible to determine which values were modified from their defaults.
One thing that truly annoys me about
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
One thing that truly annoys me about postgresql.conf is say I unhash an
option and set it to something. Then I reload. Then I edit the conf
and hash it out again, then I reload. Of course, the option still has
my old
On Wednesday 16 June 2004 03:39, Michael Glaesemann wrote:
On Jun 16, 2004, at 1:05 PM, Christopher Kings-Lynne wrote:
The proposal is to remove the comments from postgresql.conf (like
Apache) so all entries will be active. The downside is that it will
not
be possible to determine which
Tom Lane [EMAIL PROTECTED] writes:
The only real problem I see is that showing all the values as comments
encourages the idea that you can undo a change by undoing your edit.
The simple and obvious fix is to not show the values as comments ...
Well even if you don't show them (and it would
* Greg Stark ([EMAIL PROTECTED]) wrote:
Tom Lane [EMAIL PROTECTED] writes:
The only real problem I see is that showing all the values as comments
encourages the idea that you can undo a change by undoing your edit.
The simple and obvious fix is to not show the values as comments ...
Well
Stephen Frost wrote:
* Greg Stark ([EMAIL PROTECTED]) wrote:
Tom Lane [EMAIL PROTECTED] writes:
The only real problem I see is that showing all the values as comments
encourages the idea that you can undo a change by undoing your edit.
The simple and obvious fix is to not show the values
Tom, folks:
The only real problem I see is that showing all the values as comments
encourages the idea that you can undo a change by undoing your edit.
The simple and obvious fix is to not show the values as comments ...
I'll say!I've been testing PostgreSQL.conf settings, writing docs
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The only real problem I see is that showing all the values as comments
encourages the idea that you can undo a change by undoing your edit.
The simple and obvious fix is to not show the values as comments ...
I agree.
A good way how to
Andreas Pflug [EMAIL PROTECTED] writes:
How about *requiring* to set any variable, at least to xxx='default'?
Don't like that ... we are not in the fascism business here ;-).
How would you enforce it anyway?
The idea of special-casing
var = default
(with no quotes around 'default')
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
How about *requiring* to set any variable, at least to xxx='default'?
Don't like that ... we are not in the fascism business here ;-).
Well enforcing setting variables, in the presence of a preconfigured
file isn't exactly
Andreas Pflug [EMAIL PROTECTED] writes:
How about vars overridden on the postmaster command line? Similar issue,
I believe. Naively, I'd assume that my last instruction (in this case:
changing postgresql.conf and SIGHUP) would determine processing, which
is obviously wrong if I read the
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
How about vars overridden on the postmaster command line? Similar issue,
I believe. Naively, I'd assume that my last instruction (in this case:
changing postgresql.conf and SIGHUP) would determine processing, which
is obviously
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
How about *requiring* to set any variable, at least to xxx='default'?
Don't like that ... we are not in the fascism business here ;-).
It would just make it too hard to add new variables.
Tom Lane wrote:
That was another point I was about to make, which is that there are lots
of other reasons why the active value of some config variable might not
be what postgresql.conf says. We are *not* ripping out the entire GUC
facility just because some people haven't bothered to read the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Try yourself, I did the experiment changing the cpu_tuple_cost and
commenting out the cpu_tuple_cost, after sending the SIGHUP to
postmaster the value remain: 0.005 that is not the default value at
all.
Ducking the added documentation
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Try yourself, I did the experiment changing the cpu_tuple_cost and
commenting out the cpu_tuple_cost, after sending the SIGHUP to
Bruce Momjian [EMAIL PROTECTED] writes:
The proposal is to remove the comments from postgresql.conf (like
Apache) so all entries will be active. The downside is that it will not
be possible to determine which values were modified from their defaults.
I think the latter is a nontrivial cost.
The proposal is to remove the comments from postgresql.conf (like
Apache) so all entries will be active. The downside is that it will not
be possible to determine which values were modified from their defaults.
One thing that truly annoys me about postgresql.conf is say I unhash an
option and
Scott Marlowe wrote:
On Fri, 2004-06-11 at 11:02, Bruce Momjian wrote:
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|Bruce Momjian wrote:
|
| I understand your points below. However,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|Bruce Momjian wrote:
|
| I understand your points below. However, the group has weighed in the
| direction of clearly showing non-default values and not duplicating
| documentation. We can change
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|Bruce Momjian wrote:
|
| I understand your points below. However, the group has weighed in the
| direction of clearly
On Fri, 2004-06-11 at 11:02, Bruce Momjian wrote:
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|Bruce Momjian wrote:
|
| I understand your points below.
On Wed, Jun 09, 2004 at 09:13:05PM +0530, Shridhar Daithankar wrote:
Well that is easy. In the service file just say
[Cluster1]
datapath=/data/foo
[Cluster2]
datapath=/data/foo1
and postgresql.conf could still reside inside each cluster to provide
specific configuration.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We discussed this and thought that it would end up duplicating stuff
already in the docs
Which is fine. Keeping some documentation in the file itself is a
necessity. For example, we've changed sort_mem to work_mem.
There should at the least be
Dear Greg,
One idea that has been floated around is to pull the docs automatically
from SGML and put them in postgresql.conf. We do that for psql's use of
\help now, so it seems this is possible.
I'm not sure this is the way to go. The SGML should be more detailed, and
also assumes
I understand your points below. However, the group has weighed in the
direction of clearly showing non-default values and not duplicating
documentation. We can change that, but you will need more folks
agreeing with your direction.
Bruce Momjian wrote:
I understand your points below. However, the group has weighed in the
direction of clearly showing non-default values and not duplicating
documentation. We can change that, but you will need more folks
agreeing with your direction.
I don't remember the behaviour but tell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(warning: rehashing of issues ahead)
Sometimes when I talk to technical people about using PostgreSQL,
I get a strong reaction along the lines of it's ugly, complex, and
hard to set up. While we have gotten better than we used to be,
some of
We discussed this and thought that it would end up duplicating stuff
already in the docs, and removing the comments means that you have no
way to know which are being set to non-default values. Both seem to be
a loss.
Are people saying the Apache config files are easier to use? I actually
find
I have a LOT of opinions about postgresql.conf, and frankly, I think more
comments are not where the problems lie.
If you *really* want to make configuring postgresql easier,
postgresql.conf HAS to live outside the data directory and specify where
everything is. postgresql.conf should do exactly
[EMAIL PROTECTED] wrote:
I have a LOT of opinions about postgresql.conf, and frankly, I think more
comments are not where the problems lie.
If you *really* want to make configuring postgresql easier,
postgresql.conf HAS to live outside the data directory and specify where
everything is.
Bruce Momjian [EMAIL PROTECTED] writes:
One idea that has been floated around is to pull the docs automatically
from SGML and put them in postgresql.conf.
In theory, postgresql.conf.sample could be a generated file: pull the
docs from SGML and the default values from the GUC tables. However
On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
Well, the statement 'postgresql.conf outside data directory' isn't going to
win I think.
One day there won't be any data directory because the data will be
on raw partitions. Then you will _have_ to have the configuration
Greg Sabino Mullane wrote:
(warning: rehashing of issues ahead)
[snipped: suggestion to have much more documentation in sample postgresql.conf]
Wasn't RedHat working on a configuration utility for Postgres? That
seems to me like a much more productive way to go.
cheers
andrew
Honza Pazdziora wrote:
On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
Well, the statement 'postgresql.conf outside data directory' isn't going to
win I think.
One day there won't be any data directory because the data will be
on raw partitions. Then you will _have_ to have
39 matches
Mail list logo
