Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > The goal here is simply to make it obvious to a system administrator where
> > the PG data directory that a given postmaster is using resides.
>
> Why would it not be sufficient to add a read-only GUC variable that
> tells that? Connec
Joe Conway wrote:
Tom Lane wrote:
Personally I rely quite a lot on setting PGDATA to keep straight which
installation I'm currently working with, so I'm not going to be happy
with a redesign that eliminates that variable without providing an
adequate substitute :-(
I'll second that.
I'll thir
Kevin Brown <[EMAIL PROTECTED]> writes:
> The goal here is simply to make it obvious to a system administrator where
> the PG data directory that a given postmaster is using resides.
Why would it not be sufficient to add a read-only GUC variable that
tells that? Connect to the postmaster and do "
Simon Riggs wrote:
> Very much agreed. PGDATA is important, lets keep it, please.
To me it's not so much whether or not PGDATA is kept around for the
system as a whole so much as how it's used.
In the general case, scripts are used to start the postmaster. So using
PGDATA even if the postmaster
Joe Conway wrote
> Tom Lane wrote:
> > Personally I rely quite a lot on setting PGDATA to keep
> straight which
> > installation I'm currently working with, so I'm not going
> to be happy
> > with a redesign that eliminates that variable without providing an
> > adequate substitute :-(
>
> I'll se
Mark Kirkwood wrote:
Tom Lane wrote:
I think if you spelled the subdir name "config" rather than "etc",
it would be more obvious what's what.
How about 'conf' - (familiar to anyone who has used apache or tomcat )
How about 'etc' - (familiar ot anyone who has used unix)
--
Andrew Hammond
-
Tom Lane wrote:
Personally I rely quite a lot on setting PGDATA to keep straight which
installation I'm currently working with, so I'm not going to be happy
with a redesign that eliminates that variable without providing an
adequate substitute :-(
I'll second that.
Joe
---
Robert Treat <[EMAIL PROTECTED]> writes:
> On Tuesday 13 April 2004 01:14, Kevin Brown wrote:
>> To be honest, I think the use of the PG_DATA environment variable is the
>> biggest impediment to "self documentation" - the postmaster should not
>> use it.
> I think this is another vote for "store t
On Tuesday 13 April 2004 01:14, Kevin Brown wrote:
> Tom Lane wrote:
> To be honest, I think the use of the PG_DATA environment variable is the
> biggest impediment to "self documentation" - the postmaster should not
> use it.
>
> The reason is that if PG_DATA is used to specify the location of th
Tom Lane wrote:
I think if you spelled the subdir name "config" rather than "etc",
it would be more obvious what's what.
How about 'conf' - (familiar to anyone who has used apache or tomcat )
regards
Mark
---(end of broadcast)---
TIP 4: Don
[EMAIL PROTECTED] wrote:
ii) I think the -C switch *WITH* the -D switch has viable usability.
Consider this, you are testing two different database layouts and/or RAID
controllers. You could easily bounce back and forth from *identical*
configurations like this:
Convenient indeed, but I would l
Bruce Momjian wrote:
Let me tell you the compromise I thought of.
First, we put the config files (postgresql.conf, pg_hba.conf,
pg_ident.conf) in data/etc by default.
Sorry Bruce,
I was being slow :-) , I was thinking you were going to associate the
config files with the binary distributio
Tom Lane wrote:
> Well, the patch says that the command line switch wins, which is
> consistent with what we do for other command line switches (they all
> override the equivalent postgresql.conf entries). This does seem a
> bit at variance with the stated goal of making the configuration more
> c
[EMAIL PROTECTED] wrote:
>>I just had a thought about this: seems like a big part of the objection
>>is the risk of specifying -C and -D that don't go together. Well, what
>>if they were the same switch? Consider the following simplification of
>>the proposed patch:
>>
>>
>
>I was really exc
Bruce Momjian wrote:
>Thomas Swan wrote:
>
>
>>I thought the idea was to *reduce* the number of config files and provide
>>a unified configuration file. Ideally, the unified configuration file
>>could eliminate the need for environment variables altogether.
>>
>>If I understand this correctly,
> I just had a thought about this: seems like a big part of the objection
> is the risk of specifying -C and -D that don't go together. Well, what
> if they were the same switch? Consider the following simplification of
> the proposed patch:
I was really excited about this idea, then I thought a
I just had a thought about this: seems like a big part of the objection
is the risk of specifying -C and -D that don't go together. Well, what
if they were the same switch? Consider the following simplification of
the proposed patch:
1. Postmaster has just one switch, '-D datadir' with fallback
> [EMAIL PROTECTED] wrote:
>> > The bottom line to me is that config versus data ought to be a one-to-
>> > many relationship, at least if you accept the premise that shared
>> config
>> > is reasonable at all. Putting a datadir spec inside the config file
>> > makes it impossible to share config
[EMAIL PROTECTED] writes:
>> Well, it doesn't *require* it, but if you actually *use* the patch in
>> the proposed way then you end up with the error-prone need to specify
>> the correct combination of -C and -D on the command line. I think what
>> people are questioning is whether we can't find a
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... it isn't clear which files to touch. After the reorganization it
> > would be:
>
> > PG_VERSION global/ postmaster.opts
> > base/ pg_clog/postmaster.pid
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... it isn't clear which files to touch. After the reorganization it
> would be:
> PG_VERSION global/ postmaster.opts
> base/ pg_clog/postmaster.pid
> etc/
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > My personal opinion is that we should move the config files from
> > pgsql/data to pgsql/data/etc. Unix config files aren't put in /,
> > they are in /etc, so this seems logical. I was never comfortable
> > with having editable files right next t
Bruce Momjian wrote:
> My personal opinion is that we should move the config files from
> pgsql/data to pgsql/data/etc. Unix config files aren't put in /,
> they are in /etc, so this seems logical. I was never comfortable
> with having editable files right next to files that shouldn't be
> touche
Bruce Momjian <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> What if someone does -C /var/data/postgresql.conf, and postgresql.conf
> say to use /usr/local/data for data, what do we do?
Well, the patch says that the command line switch wins, which is
consistent with what we do for other
[EMAIL PROTECTED] wrote:
> > The bottom line to me is that config versus data ought to be a one-to-
> > many relationship, at least if you accept the premise that shared config
> > is reasonable at all. Putting a datadir spec inside the config file
> > makes it impossible to share config files acr
> Stephan Szabo <[EMAIL PROTECTED]> writes:
>> On Mon, 12 Apr 2004, Bruce Momjian wrote:
>>> I think the major problem with your -C & -D idea is that you require
>>> the
>>> administrator to link the config file and data directory everytime you
>>> start the db, and that might be error-prone.
>
>>
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Mon, 12 Apr 2004, Bruce Momjian wrote:
>> I think the major problem with your -C & -D idea is that you require the
>> administrator to link the config file and data directory everytime you
>> start the db, and that might be error-prone.
> Well, AFAICS
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My personal opinion is that we should move the config files from
> > pgsql/data to pgsql/data/etc. Unix config files aren't put in /, they
> > are in /etc, so this seems logical. I was never comfortable with having
> > editable files
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Obviously, we need to do something. There are just too many people who
>> want improvement in this area. The question is what changes to make.
[snip]
>
> The whole discussion reminds me quite a bit of Tom Lockhart's patch to
> specify WAL file locati
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My personal opinion is that we should move the config files from
> pgsql/data to pgsql/data/etc. Unix config files aren't put in /, they
> are in /etc, so this seems logical. I was never comfortable with having
> editable files right next to files that
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Obviously, we need to do something. There are just too many people who
> > want improvement in this area. The question is what changes to make.
>
> As far as I've seen in this thread, there's only *one* person arguing
> for change,
> The only other idea I can think of is to create a new pg_path.conf file.
> It would have the same format as postgresql.conf, but contain
> information about /data location, config file location, and perhaps
> pg_xlog location.
>
> The file would be created by special flags to initdb, and once cr
> [EMAIL PROTECTED] wrote:
>> > The only other idea I can think of is to create a new pg_path.conf
>> file.
>> > It would have the same format as postgresql.conf, but contain
>> > information about /data location, config file location, and perhaps
>> > pg_xlog location.
>> >
>> > The file would be
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Obviously, we need to do something. There are just too many people who
> want improvement in this area. The question is what changes to make.
As far as I've seen in this thread, there's only *one* person arguing
for change, and even he isn't advocating
Thomas Swan wrote:
> I thought the idea was to *reduce* the number of config files and provide
> a unified configuration file. Ideally, the unified configuration file
> could eliminate the need for environment variables altogether.
>
> If I understand this correctly, the author was adding the abi
On Mon, 12 Apr 2004, Bruce Momjian wrote:
> [EMAIL PROTECTED] wrote:
> > > The only other idea I can think of is to create a new pg_path.conf file.
> > > It would have the same format as postgresql.conf, but contain
> > > information about /data location, config file location, and perhaps
> > > pg
[EMAIL PROTECTED] wrote:
> > The only other idea I can think of is to create a new pg_path.conf file.
> > It would have the same format as postgresql.conf, but contain
> > information about /data location, config file location, and perhaps
> > pg_xlog location.
> >
> > The file would be created by
On Sunday 11 April 2004 11:56, [EMAIL PROTECTED] wrote:
> > On Sat, Apr 10, 2004 at 03:53:49PM -0400, [EMAIL PROTECTED] wrote:
> For all the people who would like PostgreSQL to fit in a FHS system,
> easily, they will probably use it. In fact, I would bet real money, that
> if this functionality is
> The only other idea I can think of is to create a new pg_path.conf file.
> It would have the same format as postgresql.conf, but contain
> information about /data location, config file location, and perhaps
> pg_xlog location.
>
> The file would be created by special flags to initdb, and once cre
The only other idea I can think of is to create a new pg_path.conf file.
It would have the same format as postgresql.conf, but contain
information about /data location, config file location, and perhaps
pg_xlog location.
The file would be created by special flags to initdb, and once created,
would
Bruce Momjian wrote:
Mark Kirkwood wrote:
Bruce Momjian wrote:
My idea was to put config files in /usr/local/pgsql/data/etc, not
pgsql/etc.
We don't put Unix configuration files in /, etc put them in /etc.
Sorry, I missed the 'data' pathname. However - I may be a bit slow - bu
> [EMAIL PROTECTED] wrote:
>> > Obviously, we need to do something. There are just too many people
>> who
>> > want improvement in this area. The question is what changes to make.
>> >
>> > My personal opinion is that we move the config files in /data/etc, and
>> > allow admins to move that direc
> [EMAIL PROTECTED] wrote:
>
>>
>>IMHO my patch can do this in a self
>>documenting way, thus making it easier to do, i.e.
>>
>>postmaster -C /etc/postgres/fundb.conf
>>postmaster -C /etc/postgres/testdb.conf
>>
>>I think that is far more intuitive than:
>>
>>postmaster -D /some/path/who/knows/wher
Mark Kirkwood wrote:
> Bruce Momjian wrote:
>
> > My idea was to put config files in /usr/local/pgsql/data/etc, not
> >
> >pgsql/etc.
> >
> >We don't put Unix configuration files in /, etc put them in /etc.
> >
> >
> >
> Sorry, I missed the 'data' pathname. However - I may be a bit slow - but
>
Bruce Momjian wrote:
My idea was to put config files in /usr/local/pgsql/data/etc, not
pgsql/etc.
We don't put Unix configuration files in /, etc put them in /etc.
Sorry, I missed the 'data' pathname. However - I may be a bit slow - but
I do not see how this will handle the situation where
[EMAIL PROTECTED] wrote:
> > Obviously, we need to do something. There are just too many people who
> > want improvement in this area. The question is what changes to make.
> >
> > My personal opinion is that we move the config files in /data/etc, and
> > allow admins to move that directory somew
Mark Kirkwood wrote:
> I seems to me that the existing situation is actually correct :
>
> The configuration is a property of the initialized database cluster, so
> a logical place for it is in the root of said cluster.
>
> It is *not* a property of the installed binary distribution (e.g
> /usr
[EMAIL PROTECTED] wrote:
IMHO my patch can do this in a self
documenting way, thus making it easier to do, i.e.
postmaster -C /etc/postgres/fundb.conf
postmaster -C /etc/postgres/testdb.conf
I think that is far more intuitive than:
postmaster -D /some/path/who/knows/where/fundb
postmaster -D /ano
> On Sat, Apr 10, 2004 at 03:53:49PM -0400, [EMAIL PROTECTED] wrote:
>> > The whole idea of having multiple command-line switches to pick config
>> > and data separately bothers me. ISTM this would mostly create great
>> new
>> > opportunities to shoot yourself in the foot (by accidentally picking
On Sat, Apr 10, 2004 at 03:53:49PM -0400, [EMAIL PROTECTED] wrote:
> > The whole idea of having multiple command-line switches to pick config
> > and data separately bothers me. ISTM this would mostly create great new
> > opportunities to shoot yourself in the foot (by accidentally picking the
> >
> I seems to me that the existing situation is actually correct :
>
> The configuration is a property of the initialized database cluster, so
> a logical place for it is in the root of said cluster.
>
> It is *not* a property of the installed binary distribution (e.g
> /usr/local/pgsql/etc) - as yo
I seems to me that the existing situation is actually correct :
The configuration is a property of the initialized database cluster, so
a logical place for it is in the root of said cluster.
It is *not* a property of the installed binary distribution (e.g
/usr/local/pgsql/etc) - as you may have
> Tom Lane wrote:
>> [EMAIL PROTECTED] writes:
>> > I am neither suggesting nor implementing any change in the current
>> default
>> > behavior of PostgreSQL. I am merely adding features that would make it
>> > easier to do things like configure from a centralized directory which
>> is
>> > differe
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I am neither suggesting nor implementing any change in the current default
> > behavior of PostgreSQL. I am merely adding features that would make it
> > easier to do things like configure from a centralized directory which is
> > different than the d
> [EMAIL PROTECTED] writes:
>> I am neither suggesting nor implementing any change in the current
>> default
>> behavior of PostgreSQL. I am merely adding features that would make it
>> easier to do things like configure from a centralized directory which is
>> different than the data directory, th
[EMAIL PROTECTED] writes:
> I am neither suggesting nor implementing any change in the current default
> behavior of PostgreSQL. I am merely adding features that would make it
> easier to do things like configure from a centralized directory which is
> different than the data directory, the ability
>
> On Fri, 9 Apr 2004, Christopher Browne wrote:
>>
>> ...Tom ... commented that all of the core developers make extensive use
>> of the notion of having _many_ backends around, and therefore ...
>>
>> Core folk aren't likely to write up patches designed to shoot
>> themselves in the foot this way
On Fri, 9 Apr 2004, Christopher Browne wrote:
>
> ...Tom ... commented that all of the core developers make extensive use
> of the notion of having _many_ backends around, and therefore ...
>
> Core folk aren't likely to write up patches designed to shoot
> themselves in the foot this way ...
I's
> Robert Treat <[EMAIL PROTECTED]> writes:
>> On Thu, 2004-04-08 at 09:49, [EMAIL PROTECTED] wrote:
>>> (2) I would bet that *most* deployments of PostgreSQL only use one
database environment per server, so I'm not even sure that it would be
an
>>> issue for the majority of current or prospective u
In the last exciting episode, [EMAIL PROTECTED] (Kevin Brown) wrote:
> If we want to be a bit paranoid (justifiable if you've got really
> important data on the line), we could also require that a version
> string exist in the config file. If the version string doesn't match
> the version of the p
Kevin Brown wrote:
If we're truly concerned about the possibility of multiple installations
attempting to use the same config, then the answer is simple: require
that the location of the config file be specified on the command line
and don't compile a default location into the binary. Similarly
Tom Lane wrote:
> Honza Pazdziora <[EMAIL PROTECTED]> writes:
> > On Thu, Apr 08, 2004 at 10:31:44AM -0400, Tom Lane wrote:
> >> It seems that MySQL *will* read /etc/my.cnf if it
> >> exists, whether it's appropriate or not, and so it's impossible to have
> >> a truly independent test installation,
> Robert Treat <[EMAIL PROTECTED]> writes:
>> On Thu, 2004-04-08 at 09:49, [EMAIL PROTECTED] wrote:
>>> (2) I would bet that *most* deployments of PostgreSQL only use one
>>> database environment per server, so I'm not even sure that it would be
>>> an
>>> issue for the majority of current or prosp
On Thu, Apr 08, 2004 at 11:32:19AM -0400, Tom Lane wrote:
>
> > A counterexample of Apache shows that you can easily use -f or another
> > command line option to point the server to alternate master config
> > file (which I believe is the same with MySQL).
>
> According to
> http://www.mysql.com/
Robert Treat <[EMAIL PROTECTED]> writes:
> On Thu, 2004-04-08 at 09:49, [EMAIL PROTECTED] wrote:
>> (2) I would bet that *most* deployments of PostgreSQL only use one
>> database environment per server, so I'm not even sure that it would be an
>> issue for the majority of current or prospective use
On Thu, 2004-04-08 at 09:49, [EMAIL PROTECTED] wrote:
> > On Thu, 8 Apr 2004 [EMAIL PROTECTED] wrote:
> >
> >> more flexable configuration based on the idea that configuration and
> >> data
> >> are in SEPARATE locations is important.
> >
> > Why is it important and wouldn't it just make it harder
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
>> On Thu, 8 Apr 2004 [EMAIL PROTECTED] wrote:
>>> more flexable configuration based on the idea that configuration and
>>> data
>>> are in SEPARATE locations is important.
>
>> Why is it important and wouldn't it just make it harder to have several
>>
Honza Pazdziora <[EMAIL PROTECTED]> writes:
> On Thu, Apr 08, 2004 at 10:31:44AM -0400, Tom Lane wrote:
>> It seems that MySQL *will* read /etc/my.cnf if it
>> exists, whether it's appropriate or not, and so it's impossible to have
>> a truly independent test installation, even though you can confi
Tom Lane wrote:
I've recently had some very unpleasant experiences trying to install
test versions of MySQL on machines that already had older versions
installed normally. It seems that MySQL *will* read /etc/my.cnf if it
exists, whether it's appropriate or not, and so it's impossible to have
a tr
I have the file location discussion in my 7.4 hold mailbox:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
I am going to revisit it the next month and see if I can get all the
opinions merged into a plan everyone can agree on. I think it can be
done.
--
On Thu, Apr 08, 2004 at 10:31:44AM -0400, Tom Lane wrote:
>
> I've recently had some very unpleasant experiences trying to install
> test versions of MySQL on machines that already had older versions
> installed normally. It seems that MySQL *will* read /etc/my.cnf if it
> exists, whether it's ap
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Thu, 8 Apr 2004 [EMAIL PROTECTED] wrote:
>> more flexable configuration based on the idea that configuration and data
>> are in SEPARATE locations is important.
> Why is it important and wouldn't it just make it harder to have several
> database c
> On Thu, 8 Apr 2004 [EMAIL PROTECTED] wrote:
>
>> more flexable configuration based on the idea that configuration and
>> data
>> are in SEPARATE locations is important.
>
> Why is it important and wouldn't it just make it harder to have several
> database clusters (for example with different loca
On Thu, 8 Apr 2004 [EMAIL PROTECTED] wrote:
> more flexable configuration based on the idea that configuration and data
> are in SEPARATE locations is important.
Why is it important and wouldn't it just make it harder to have several
database clusters (for example with different locale) or sever
About a year or two ago I submitted a configuration patch that allowed
PostgreSQL to be fully configured by postgresql.conf -- enabling data and
configuration to be in separate locations. The idea was that, like most
UNIX systems, that the configuration file could be stored in the /etc
directory (o
75 matches
Mail list logo
