Hi,
Josh Berkus 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 which allows
>> 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
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
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 o
> 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
Bruce Momjian 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 mentioned earlier
On Tue, Nov 10, 2009 at 2:19 PM, Bruce Momjian 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 postgresql.conf
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 be
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
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.
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 addition
"Joshua D. Drake" 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."?
Reading files in a
On Thu, Oct 29, 2009 at 11:38 AM, Tom Lane wrote:
> Robert Haas 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
>> res
Tom Lane wrote:
Andrew Dunstan 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
On Thu, 2009-10-29 at 11:42 -0400, Tom Lane wrote:
> Andrew Dunstan 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
Andrew Dunstan 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 same thing if startin
Robert Haas 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 that namespace".
Joshua D. Drake wrote:
On Thu, 2009-10-29 at 12:31 +, Thom Brown wrote:
2009/10/29 Andrew Dunstan :
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 tha
On Thu, Oct 29, 2009 at 9:44 AM, Tom Lane wrote:
> Andrew Dunstan 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'"
On Thu, 2009-10-29 at 12:31 +, Thom Brown wrote:
> 2009/10/29 Andrew Dunstan :
> > 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 the c
>>
>>
>
> 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'" a
Thom Brown 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 improvement of any
Andrew Dunstan 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 actually b
Pavel Stehule wrote:
2009/10/29 Andrew Dunstan :
Pavel Stehule wrote:
2009/10/27 Simon Riggs :
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_
2009/10/29 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> 2009/10/27 Simon Riggs :
>>
>>>
>>> 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 t
2009/10/29 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> 2009/10/27 Simon Riggs :
>>
>>>
>>> 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 t
Pavel Stehule wrote:
2009/10/27 Simon Riggs :
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 yo
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
On Wed, 2009-10-28 at 09:39 -0700, Greg Stark wrote:
> On Wed, Oct 28, 2009 at 7:33 AM, Alvaro Herrera
> 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 packag
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 o
2009/10/27 Simon Riggs :
> 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 variab
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
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 r
On Wed, Oct 28, 2009 at 4:52 PM, Greg Smith 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 into the prop
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 th
On Wed, Oct 28, 2009 at 4:24 PM, Josh Berkus 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 time goe
> 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 c
On Wed, Oct 28, 2009 at 3:28 PM, Tom Lane wrote:
> Josh Berkus 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.
>
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
discus
Josh Berkus 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 perl, and in
On Wed, Oct 28, 2009 at 12:08 PM, Josh Berkus 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 that. It *loo
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* p
On Wed, Oct 28, 2009 at 10:28 AM, Greg Smith 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 installed by
> the package
Greg Smith 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 insane. The whol
Josh Berkus 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" -- but perhaps
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
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 was
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 co
On Wed, Oct 28, 2009 at 2:37 AM, Dimitri Fontaine
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 was trying to do.
>>
On Wed, Oct 28, 2009 at 7:33 AM, Alvaro Herrera
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. If you edit the user'
Greg Smith 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 changes to them; it ju
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
Alvaro Herrera 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 talking about how th
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 s
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 Herrerahttp://www
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
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 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 t
On Tue, Oct 27, 2009 at 11:40 PM, Josh Berkus 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 write out t
Greg Stark writes:
> On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus 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 b
On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus 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 the difficulty
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 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, Oct 27, 2009 at 10:53 PM, Tom Lane wrote:
> Robert Haas 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.
Robert Haas 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 don't seem to get is
On Tue, Oct 27, 2009 at 9:05 PM, Josh Berkus 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 individual
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
sho
On Tue, Oct 27, 2009 at 2:59 PM, Greg Stark wrote:
> On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas 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 w
--
dim
Le 27 oct. 2009 à 18:21, Tom Lane a écrit :
Greg Smith 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 th
Hi,
Phone quoting again...
--
dim
Le 27 oct. 2009 à 18:06, Greg Smith 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
postgresql.conf file.
Way upthrea
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.
E
Greg Stark 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 matters for automat
On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas 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 has nothing to do wi
On Tue, 2009-10-27 at 13:21 -0400, Tom Lane wrote:
> Greg Smith 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 Tue, Oct 27, 2009 at 1:21 PM, Tom Lane wrote:
> Greg Smith 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
Greg Smith 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 config-adjustment tool
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
> configu
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 conferen
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 th
Greg Smith 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 counties that fil
Hi,
Greg Smith 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 this:
>
> include
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 (pgsql-hackers@po
On Mon, 2009-10-26 at 14:13 -0700, Greg Stark wrote:
> On Mon, Oct 26, 2009 at 1:40 PM, Josh Berkus 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. memory.conf,
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 this:
includedir 'conf'
With the same basic s
Greg Smith writes:
> On Mon, 26 Oct 2009, Greg Stark wrote:
>> When scanning postgresql.conf.d we should follow the Apache/Debian
>> standard of scanning only files which match a single simple hard-coded
>> template.
> If the default glob pattern is *.conf, won't all those already be screened
On Mon, Oct 26, 2009 at 6:55 PM, Greg Smith wrote:
> If the default glob pattern is *.conf, won't all those already be screened
> out? I can see your point that letting it be adustable will inevitably
> result in some fool one day writing a bad matching pattern that does grab
> backup/lock files.
On Mon, 26 Oct 2009, Greg Stark wrote:
When scanning postgresql.conf.d we should follow the Apache/Debian
standard of scanning only files which match a single simple hard-coded
template. I think the convention is basically the regexp
^[0-9a-zA-Z-]*.conf$. It's important that it exclude typical
On Mon, 26 Oct 2009, Kevin Grittner wrote:
We do find the include capabilities useful. For example, 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/.
On Mon, Oct 26, 2009 at 3:30 PM, Josh Berkus wrote:
> Greg,
>
>> This actually seems like a bad idea to me.
>
> You write your tool your way, I'll write my tool mine. We'll see which
> one works the best in the field.
Yeah actually I meant to but YMMV on that comment and forgot.
>
>> Well you'r
Greg,
> This actually seems like a bad idea to me.
You write your tool your way, I'll write my tool mine. We'll see which
one works the best in the field.
> Well you're assuming there's only one tool generating this config? We
> have at least two and possibly more. initdb generates an initial
On Mon, 26 Oct 2009, Greg Stark wrote:
Actually I think the include directory came from another use case
which we've also discussed. Namely modules which need some
configuration themselves. So for example when you install PostGIS it
could drop a postgis.conf in the directory which you could th
+1
Would you make it +2?
--
dim
Le 26 oct. 2009 à 19:15, Greg Stark a écrit :
On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane wrote:
I think we should have an explicit include-directory directive, and
the
reason I think so is that it makes it fairly easy for the user to
control the relati
On Mon, Oct 26, 2009 at 1:40 PM, Josh Berkus 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. memory.conf, logging.conf, custom_options.conf
> ...). I do this with my A
On Mon, Oct 26, 2009 at 4:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not sure whether you're saying that I'm bringing this issue up in
>> the wrong thread, or whether you disagree with the basic suggestion.
>
> The former --- whether we want to trim down the commentary in
> postgresql.co
On Mon, Oct 26, 2009 at 8:07 AM, 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.)
Actually I think the include directory came from another use case
which we've also discussed. Namely mo
On 10/26/09 9:01 AM, Robert Haas 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.)
>
> I was starting to wonder that, too.
Different issue, really, which is that some people (including me)
Robert Haas writes:
> I'm not sure whether you're saying that I'm bringing this issue up in
> the wrong thread, or whether you disagree with the basic suggestion.
The former --- whether we want to trim down the commentary in
postgresql.conf seems to me to have nothing to do with what's
being disc
On Mon, 2009-10-26 at 10:19 -0400, Tom Lane wrote:
> Alvaro Herrera 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
> >
On Mon, Oct 26, 2009 at 7:25 AM, Alvaro Herrera
wrote:
> I agree, except that 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)
These things should go into a postgr
On Mon, Oct 26, 2009 at 7:06 AM, Alvaro Herrera
wrote:
> 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.
On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane wrote:
>
> I think we should have an explicit include-directory directive, and the
> reason I think so is that it makes it fairly easy for the user to
> control the relative precedence of the manual settings (presumed to
> still be kept in postgresql.conf)
1 - 100 of 149 matches
Mail list logo
