Hi,
Josh Berkus j...@agliodbs.com writes:
Let's NOT start that discussion again.
Don't worry, no aim here to.
Overall, I'm seeing this patch proposal suffer from an extreme excess of
bike-shedding.
Not only that. See above.
My proposal is this:
(1) that we support the idea of a patch
On Tue, 2009-11-10 at 20:14 -0800, Josh Berkus wrote:
On 11/10/09 5:59 AM, Bruce Momjian wrote:
Simon Riggs wrote:
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
And to
Let's NOT start that discussion again.
Bruce's comments were a useful addition to the technical discussion.
Yes, I'm just trying to avoid sidelining this into a discussion of
search_path management commands, which we already failed to come to a
consensus spec for earlier this year. Not
Simon Riggs wrote:
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
And to search_path, though that's even more complex because the order of
the entries is significant.
Josh Berkus wrote:
Kevin,
I'm talking about how the decision should be made as to which takes
precedence. It's fine to document which one *was* chosen, but that
doesn't eliminate the problem of conflicting settings making a mess.
Someone else (Robert maybe?) gave an explicit example
On Tue, 2009-11-10 at 08:59 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
And to search_path, though that's even more complex because
On Tue, Nov 10, 2009 at 2:19 PM, Bruce Momjian br...@momjian.us wrote:
There was discussion of whether the directory files or postgresql.conf
file has precedence. If postgresql.conf has precedence, tools changing
values might not work, and if the directory has precendence, someone
changing
Bruce Momjian br...@momjian.us wrote:
A more radical approach would be for the server to refuse to start
if a setting is set in more than one file, and for the server to
report both locations. That would reduce the guesswork about
problems.
-1
I see that as a big step backward. As
I would not complain if the server logged duplicates. (That would
actually be a minor blessing, as the startup would log all our
deviations from standard -- at least if our standard had an explicit
entry.)
I agree with Kevin here: duplicate logging +1. Not starting on
duplicates: -10^32
On 11/10/09 5:59 AM, Bruce Momjian wrote:
Simon Riggs wrote:
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
And to search_path, though that's even more complex because the order of
the
2009/10/27 Simon Riggs si...@2ndquadrant.com:
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way to match up the usage
of custom_variable_classes with this new style of .conf file processing.
At the moment if you wish to add a
On Tue, 2009-10-27 at 20:40 -0700, Josh Berkus wrote:
If you require that a tool (or SET PERISTENT) parse through a file in
order to change one setting, then you've just doubled or tripled the
code size of the tool, as well as added a host of failure conditions
which wouldn't have existed
On Wed, 2009-10-28 at 09:39 -0700, Greg Stark wrote:
On Wed, Oct 28, 2009 at 7:33 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Greg Smith escribió:
This sounds familiar...oh, that's right, this is almost the same
algorithm pgtune uses. And it sucks,
It's also a blatant
Le dimanche 25 octobre 2009 10:08:33, Peter Eisentraut a écrit :
On lör, 2009-10-24 at 13:32 -0400, Greg Smith wrote:
Regardless, the UI I was hoping for was to make the default
postgresql.conf file end with a line like this:
directory 'conf'
I think something like is this is
Pavel Stehule wrote:
2009/10/27 Simon Riggs si...@2ndquadrant.com:
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way to match up the usage
of custom_variable_classes with this new style of .conf file
2009/10/29 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
2009/10/27 Simon Riggs si...@2ndquadrant.com:
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way to match up the usage
of custom_variable_classes with
2009/10/29 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
2009/10/27 Simon Riggs si...@2ndquadrant.com:
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way to match up the usage
of custom_variable_classes with
Pavel Stehule wrote:
2009/10/29 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
2009/10/27 Simon Riggs si...@2ndquadrant.com:
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way
Andrew Dunstan and...@dunslane.net writes:
Anyway, it seems to me a whole lot better than inventing a new thing
that makes custom_variable_class as something to append to
custom_variable_classes. If you're going to insist on using append
foo = 'x' at least let it apply to the list that is
Thom Brown thombr...@gmail.com writes:
custom_variable_classes = 'x'
custom_variable_classes += 'y'
custom_variable_classes = 'z'
That would result in the first 2 assignments being undone.
That's why I don't see how having as many files as you want to *for tool
based* configuration is a
Really, they don't know any Perl or Python or Java either? Maybe.
Anyway, it seems to me a whole lot better than inventing a new thing that
makes custom_variable_class as something to append to
custom_variable_classes. If you're going to insist on using append foo =
'x' at least let it
On Thu, 2009-10-29 at 12:31 +, Thom Brown wrote:
2009/10/29 Andrew Dunstan and...@dunslane.net:
Why not allow something like += or .= instead of the = to denote appending
to a list?
custom_variable_classes += 'x'
seems a whole lot nicer to me.
I would see that as making
On Thu, Oct 29, 2009 at 9:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Anyway, it seems to me a whole lot better than inventing a new thing
that makes custom_variable_class as something to append to
custom_variable_classes. If you're going to insist on
Joshua D. Drake wrote:
On Thu, 2009-10-29 at 12:31 +, Thom Brown wrote:
2009/10/29 Andrew Dunstan and...@dunslane.net:
Why not allow something like += or .= instead of the = to denote appending
to a list?
custom_variable_classes += 'x'
seems a whole lot nicer to me.
Robert Haas robertmh...@gmail.com writes:
Another option would be to introduce a section syntax, something like
what M$ does. We could define a line that contains just [foo] to mean
define foo as a custom variable class and automatically put all the
rest of the settings in this section into
Andrew Dunstan and...@dunslane.net writes:
The whole config file is a joke. We'd never do it the way we do if we
were designing it from scratch,
Why not, pray tell? We did design it from scratch, once upon a time,
and I don't see that the design is so obviously broken that we'd not
do the
On Thu, 2009-10-29 at 11:42 -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The whole config file is a joke. We'd never do it the way we do if we
were designing it from scratch,
Why not, pray tell? We did design it from scratch, once upon a time,
and I don't see that
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The whole config file is a joke. We'd never do it the way we do if we
were designing it from scratch,
Why not, pray tell? We did design it from scratch, once upon a time,
and I don't see that the design is so obviously
On Thu, Oct 29, 2009 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Another option would be to introduce a section syntax, something like
what M$ does. We could define a line that contains just [foo] to mean
define foo as a custom variable class and
Joshua D. Drake j...@commandprompt.com writes:
In regards to parsing files in a directory. It makes sense. Why the
implementation is so difficult is beyond me. Can't we just look at
Apache and say, Gee, it may not be perfect but it does everything we
need, let's use their implementation.?
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
---
On Wed, 2009-10-28 at 22:00 +, Simon Riggs wrote:
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional
Greg Stark gsst...@mit.edu writes:
On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus j...@agliodbs.com wrote:
You're hearing from the people who are working on tools: requiring that
any tool parse a hand-written config file is a non-starter.
It can be done, pgadmin actually does it currently. But
On Tue, Oct 27, 2009 at 11:40 PM, Josh Berkus j...@agliodbs.com wrote:
On 10/27/09 8:24 PM, Robert Haas wrote:
read the old postgresql.conf and
write it back out to a new file line by line. If, in the process of
doing this, you find a setting for the variable you're trying to
change, then
Forgive me for jumping in again on discussion of a feature I might
never use, but as an outside observer something doesn't make sense
to me.
Josh Berkus j...@agliodbs.com wrote:
If you require that a tool (or SET PERISTENT) parse through a file
in order to change one setting, then you've
Greg Smith escribió:
I was thinking that the algorithm would be something like: Read
the old postgresql.conf and write it back out to a new file line
by line
This sounds familiar...oh, that's right, this is almost the same
algorithm pgtune uses. And it sucks, and it's a pain to covert
Kevin Grittner wrote:
But I think that's where the rub is -- when you
have more than one source for information, what's the precedence?
This is not a problem nowadays because that info is in pg_settings.
File name and line number.
--
Alvaro Herrera
Alvaro Herrera wrote:
Greg Smith escribió:
I was thinking that the algorithm would be something like: Read
the old postgresql.conf and write it back out to a new file line
by line
This sounds familiar...oh, that's right, this is almost the same
algorithm pgtune uses. And it
Alvaro Herrera alvhe...@commandprompt.com wrote:
Kevin Grittner wrote:
But I think that's where the rub is -- when you
have more than one source for information, what's the precedence?
This is not a problem nowadays because that info is in pg_settings.
File name and line number.
I'm
On Wed, 28 Oct 2009, Alvaro Herrera wrote:
Huh, isn't this code in initdb.c already?
The sketched out design I have for a contrib/pgtune in C presumes that I'd
start by refactoring the relevant bits from initdb into a library for both
programs to use. But the initdb code doesn't care about
Greg Smith gsm...@gregsmith.com writes:
The sketched out design I have for a contrib/pgtune in C presumes that I'd
start by refactoring the relevant bits from initdb into a library for both
programs to use. But the initdb code doesn't care about preserving
existing values when making
On Wed, Oct 28, 2009 at 7:33 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Greg Smith escribió:
This sounds familiar...oh, that's right, this is almost the same
algorithm pgtune uses. And it sucks,
It's also a blatant violation of packaging rules for Debian if not
every distribution.
On Wed, Oct 28, 2009 at 2:37 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
That's why I'm proposing the following API at file level:
That's exactly the same as putting them all in the same file, only a
different syntax. It still requires that any program understand what
every other program
Kevin,
I'm talking about how the decision should be made as to which takes
precedence. It's fine to document which one *was* chosen, but that
doesn't eliminate the problem of conflicting settings making a mess.
Someone else (Robert maybe?) gave an explicit example of how three
files could
On Wed, 28 Oct 2009, Tom Lane wrote:
Why in the world are you looking at initdb? The standard reference for
postgresql.conf-reading code, by definition, is guc-file.l. I think the
odds of building something that works right, without borrowing that same
flex logic, are about nil.
initdb
On Wed, 28 Oct 2009, Greg Stark wrote:
It's also a blatant violation of packaging rules for Debian if not
every distribution. If you edit the user's configuration file then
there's no way to install a modified default configuration file. You
can't tell the automatic modifications apart from the
Josh Berkus j...@agliodbs.com wrote:
The precedence issues you (and Robert) are citing are no different
from what we have currently in a single file.
I think that's *why* we're mentioning it. This would seem to be the
juncture to look for ways to improve that, not just settle for no
worse
Greg Smith gsm...@gregsmith.com writes:
If as you say the only right way to do this is to use the flex logic, that
just reinforced how high the bar is for someone who wants to write a tool
that modifies the file.
Yup, exactly. Personally I think that trying to auto-modify
postgresql.conf is
On Wed, Oct 28, 2009 at 10:28 AM, Greg Smith gsm...@gregsmith.com wrote:
The postgresql.conf file being modified is generated by initdb, and it's
already being customized per install by the initdb-time rules like detection
for maximum supported shared_buffers. It isn't one of the files
Kevin,
Perhaps the ease of writing something like that with sed or perl has
caused me to underestimate the effort required in C. I am curious
whether you actually mean that, or said it for rhetorical effect.
I actually mean that. It *looks* easy in perl, and in fact *is* easy
for *your*
On Wed, Oct 28, 2009 at 12:08 PM, Josh Berkus j...@agliodbs.com wrote:
Perhaps the ease of writing something like that with sed or perl has
caused me to underestimate the effort required in C. I am curious
whether you actually mean that, or said it for rhetorical effect.
I actually mean
Josh Berkus j...@agliodbs.com writes:
Kevin,
Perhaps the ease of writing something like that with sed or perl has
caused me to underestimate the effort required in C. I am curious
whether you actually mean that, or said it for rhetorical effect.
I actually mean that. It *looks* easy in
On Wed, 28 Oct 2009, Josh Berkus wrote:
It's the basic and unsolvable issue of how do you have a file which is
both perfectly human-readable-and-editable *and* perfectly
machine-readable-and-editable at the same time.
Let's see...if I remember correctly from the last two rounds of this
On Wed, Oct 28, 2009 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
Kevin,
Perhaps the ease of writing something like that with sed or perl has
caused me to underestimate the effort required in C. I am curious
whether you actually mean that, or said it
Let's see...if I remember correctly from the last two rounds of this
discussion, this is the point where someone pops up and says that
switching to XML for the postgresql.conf will solve this problem.
Whoever does that this time goes into the ring with Kevin and I, but
they don't get a club.
On Wed, Oct 28, 2009 at 4:24 PM, Josh Berkus j...@agliodbs.com wrote:
Let's see...if I remember correctly from the last two rounds of this
discussion, this is the point where someone pops up and says that
switching to XML for the postgresql.conf will solve this problem.
Whoever does that this
On Wed, 28 Oct 2009, Robert Haas wrote:
It would be completely logical to break up the configuration file into
subfiles by TOPIC. That would complicate things for tool-writers
because they would need to get each setting into the proper file, and
we currently don't have any infrastructure for
On Wed, Oct 28, 2009 at 4:52 PM, Greg Smith gsm...@gregsmith.com wrote:
On Wed, 28 Oct 2009, Robert Haas wrote:
It would be completely logical to break up the configuration file into
subfiles by TOPIC. That would complicate things for tool-writers
because they would need to get each setting
Greg Smith wrote:
On Wed, 28 Oct 2009, Josh Berkus wrote:
It's the basic and unsolvable issue of how do you have a file which is
both perfectly human-readable-and-editable *and* perfectly
machine-readable-and-editable at the same time.
Let's see...if I remember correctly from the last two
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way to match up the usage
of custom_variable_classes with this new style of .conf file processing.
At the moment if you wish to add a custom variable class everybody needs
to edit the
On Mon, 2009-10-26 at 14:13 -0700, Greg Stark wrote:
On Mon, Oct 26, 2009 at 1:40 PM, Josh Berkus j...@agliodbs.com wrote:
Different issue, really, which is that some people (including me) would
like to break up PostgreSQL configuration into 7 or 8 files based on
functional area (e.g.
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
It sounds like there's a consensus brewing here on what should get done
with this particular patch now. Let me try to summarize:
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list
Hi,
Greg Smith gsm...@gregsmith.com writes:
It sounds like there's a consensus brewing here on what should get done with
this particular patch now. Let me try to summarize:
-The new feature should be activated by allowing you to specify a directory
to include in the postgresql.conf like
Greg Smith gsm...@gregsmith.com wrote:
On Mon, 26 Oct 2009, Kevin Grittner wrote:
for our 72 production servers for county Circuit Court systems, we
copy an identical postgresql.conf file to each county, with the
last line being an include to an overrides conf file in /etc/.
For most
On Tue, 27 Oct 2009, Dimitri Fontaine wrote:
I parse the current status as always reading files in the
postgresql.conf.d directory located in the same place as the current
postgresql.conf file.
Way upthread I pointed out that what some packagers have really wanted for
a while now is to put
On Tue, 27 Oct 2009, Kevin Grittner wrote:
I have 200 clusters. I understand the proposal. I see no benefit to
me.
-Kevin, the troglodyte ;-)
It looks like we'll have to settle this the only way your kind understands
then: a battle to the death using clubs. See you at the next
Peter,
Right, but you'll notice that Josh already got his way into how the
current postgresql.conf is laid out and how the documentation is
structured. I can't find anything in the documentation anymore. Just
as a side note ... when we start giving people new ways to access the
Greg Smith gsm...@gregsmith.com writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to more than
one.
One thing that concerns me a bit about the lack of consensus on that
is what will happen if different
On Tue, Oct 27, 2009 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith gsm...@gregsmith.com writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to more than
one.
One thing that concerns me a bit about
On Tue, 2009-10-27 at 13:21 -0400, Tom Lane wrote:
Greg Smith gsm...@gregsmith.com writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to more than
one.
One thing that concerns me a bit about the lack
On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas robertmh...@gmail.com wrote:
IME, the use case for multiple Apache configuration files is that
there are bits of configuration that support particular modules which
packagers want installed only in conjunction with the corresponding
modules - it
Greg Stark gsst...@mit.edu writes:
I still think a simple hard coded rule is more useful and than allowing
sysadmins to specify any regexp or glob and then having modules or
tools not know what's allowed or not.
Yeah. Considering that the entire argument for this feature is to
simplify
On Tue, 27 Oct 2009, Greg Stark wrote:
If they all had to edit the same file then they have to deal with
writing out values and also reading them back. Everyone would need a
config file parser and have to make deductions about what other tools
were trying to do and how to interact with them.
Hi,
Phone quoting again...
--
dim
Le 27 oct. 2009 à 18:06, Greg Smith gsm...@gregsmith.com a écrit :
On Tue, 27 Oct 2009, Dimitri Fontaine wrote:
I parse the current status as always reading files in the
postgresql.conf.d directory located in the same place as the current
--
dim
Le 27 oct. 2009 à 18:21, Tom Lane t...@sss.pgh.pa.us a écrit :
Greg Smith gsm...@gregsmith.com writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to
more than
one.
One thing that concerns me
On Tue, Oct 27, 2009 at 2:59 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas robertmh...@gmail.com wrote:
IME, the use case for multiple Apache configuration files is that
there are bits of configuration that support particular modules which
packagers want
Robert,
The Apache model is definitely the first of these, AFAICS. The
proposals on this thread mostly seem to be an amalgam of both, which
doesn't strike me as a terribly good idea, but evidently I'm in the
minority.
Well, an individual DBA would not want to do it both ways. But we
should
On Tue, Oct 27, 2009 at 9:05 PM, Josh Berkus j...@agliodbs.com wrote:
The Apache model is definitely the first of these, AFAICS. The
proposals on this thread mostly seem to be an amalgam of both, which
doesn't strike me as a terribly good idea, but evidently I'm in the
minority.
Well, an
Robert Haas robertmh...@gmail.com writes:
I guess all I'm saying is that if we took the approach of making SET
PERSISTENT rewrite postgresql.conf, we actually could let people do it
either way they pleased without the complexity of having multiple
files.
You keep saying that, but what you
On Tue, Oct 27, 2009 at 10:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I guess all I'm saying is that if we took the approach of making SET
PERSISTENT rewrite postgresql.conf, we actually could let people do it
either way they pleased without the
On 10/27/09 8:24 PM, Robert Haas wrote:
read the old postgresql.conf and
write it back out to a new file line by line. If, in the process of
doing this, you find a setting for the variable you're trying to
change, then write out the new line in place of the original line.
You've hit the
On Tue, 27 Oct 2009, Robert Haas wrote:
I guess I didn't consider the possibility that someone might reuse an
8.4 postgresql.conf on an 8.5 server. That could be awkward.
Happens all the time, and it ends up causing problems like people still
having settings for GUCs that doesn't even exist
On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus j...@agliodbs.com wrote:
You're hearing from the people who are working on tools: requiring that
any tool parse a hand-written config file is a non-starter.
It can be done, pgadmin actually does it currently. But I totally
agree it's a bad idea.
But
On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus j...@agliodbs.com wrote:
On 10/25/09 5:33 PM, Robert Haas wrote:
Greg believes that it
isn't politically feasible to change the default postgresql.conf, now
or perhaps ever. I notice that he didn't say that he thinks it's a
bad idea. So he has
On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith gsm...@gregsmith.com wrote:
On Sun, 25 Oct 2009, Robert Haas wrote:
I especially don't believe that it will ever support SET PERSISTENT, which
I believe to be a feature a lot of people want.
It actually makes it completely trivial to implement.
On Mon, 2009-10-26 at 09:04 -0400, Robert Haas wrote:
On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus j...@agliodbs.com wrote:
On 10/25/09 5:33 PM, Robert Haas wrote:
Greg believes that it
isn't politically feasible to change the default postgresql.conf, now
or perhaps ever. I notice that
Robert Haas escribió:
On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith gsm...@gregsmith.com wrote:
It actually makes it completely trivial to implement. SET PERSISTENT can
now write all the changes out to a new file in the include directory. Just
ship the database with a persistent.conf in
Alvaro Herrera alvhe...@commandprompt.com writes:
Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
automatic comment # overridden in persistent.conf and put a comment
marker in front of the original line. That way the user is led to the
actual authoritative source.
Doesn't
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
automatic comment # overridden in persistent.conf and put a comment
marker in front of the original line. That way the user is led to the
actual
On Mon, Oct 26, 2009 at 9:51 AM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2009-10-26 at 09:04 -0400, Robert Haas wrote:
On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus j...@agliodbs.com wrote:
On 10/25/09 5:33 PM, Robert Haas wrote:
Greg believes that it
isn't politically feasible to
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Personally I think this is just a matter of usage. If you want to use
SET PERSISTENT, don't set values manually in postgresql.conf.
I agree, except that some things are defined in postgresql.conf by
initdb and you probably
Robert Haas robertmh...@gmail.com writes:
What am I missing here?
You're still attacking the wrong straw man. Whether the file contains a
lot of commentary by default is NOT the problem, and removing the
commentary is NOT the solution.
regards, tom lane
--
Sent via
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribi�:
Personally I think this is just a matter of usage. If you want to use
SET PERSISTENT, don't set values manually in postgresql.conf.
I agree, except that some things are defined in postgresql.conf by
Alvaro Herrera alvhe...@commandprompt.com writes:
(But to me this also says that SET PERSISTENT has to go over
00initdb.conf and add a comment mark to the setting.)
Why? As you yourself pointed out, pg_settings will show exactly where
the active value came from. Moreover, should we then
Robert Haas robertmh...@gmail.com wrote:
I realize that the current file format is an old and familiar
friend; it is for me, too. But I think it's standing in the way of
progress. Being able to type a SQL command to update postgresql.conf
would be more substantially convenient than logging
Greg Smith gsm...@gregsmith.com writes:
People who want to continue managing just the giant postgresql.conf are
free to collapse the initdb.conf back into the larger file instead. If we
wanted to make that transition easier, an option to initdb saying do
things the old way might make
On Mon, 26 Oct 2009, Alvaro Herrera wrote:
some things are defined in postgresql.conf by initdb and you probably
want to be able to change them by SET PERSISTENT anyway (e.g.
lc_messages, listen_addresses, shared_buffers)
An obvious next step once the directory parsing is committed is to
On Mon, 26 Oct 2009, Alvaro Herrera wrote:
But to me this also says that SET PERSISTENT has to go over
00initdb.conf and add a comment mark to the setting.
Now you're back to being screwed if the server won't start because of your
change, because you've lost the original working setting.
I
Greg Smith gsm...@gregsmith.com writes:
I think the whole idea of making tools find duplicates and comment them
out as part of making their changes is fundamentally broken, and it's just
going to get worse when switching to use more config files.
Quite. There seems to me to be a whole lot
On Mon, 26 Oct 2009, Tom Lane wrote:
BTW, why do we actually need an includedir mechanism for this?
A simple include of a persistent.conf file seems like it would be
enough.
Sure, you could do it that way. This patch is more about elegance rather
than being strictly required. The general
On Mon, 26 Oct 2009, Tom Lane wrote:
When and if there is some evidence of people actually getting confused,
we could consider trying to auto-comment-out duplicate settings. But
I've never heard of any other tool doing that, and fail to see why we
should think Postgres needs to.
It's what
1 - 100 of 149 matches
Mail list logo
