Re: [HACKERS] location of the configuration files

2003-02-19 Thread Kevin Brown
Bruce Momjian wrote: I have a new idea. You know how we have search_path where you can specify multiple schema names. What if we allow the config_dirs/-C to specify multiple directories to search for config files. That way, we can use only one variable, and we can allow people to place

Re: [HACKERS] location of the configuration files

2003-02-19 Thread Andrew Dunstan
The problem I have with Bruce's scheme is that you could put your config file where you want it and someone else puts one somewhere higher in the search path and you have no idea what went wrong. It sounds to me like a recipe for an SA's nightmare. Other people have claimed to speak from the SA

Re: [HACKERS] location of the configuration files

2003-02-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: The problem I have with Bruce's scheme is that you could put your config file where you want it and someone else puts one somewhere higher in the search path and you have no idea what went wrong. It sounds to me like a recipe for an SA's nightmare.

Re: [HACKERS] location of the configuration files

2003-02-19 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I have a new idea. You know how we have search_path where you can specify multiple schema names. What if we allow the config_dirs/-C to specify multiple directories to search for config files. That way, we can use only one variable, and we can allow

Re: [HACKERS] location of the configuration files

2003-02-19 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have a new idea. You know how we have search_path where you can specify multiple schema names. What if we allow the config_dirs/-C to specify multiple directories to search for config files. That way, we can use only one

Re: [HACKERS] location of the configuration files

2003-02-19 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: The bigger question is whether you can modify config_dirs while the postmaster is running. I would think not. There would be no way to do that, because the only way to set it would be from -C on the command line or a PGCONFIG environment variable. But I

Re: [HACKERS] location of the configuration files

2003-02-18 Thread scott.marlowe
On Sat, 15 Feb 2003, Curt Sampson wrote: On Fri, 14 Feb 2003, scott.marlowe wrote: Asking for everything in a directory with the name local in it to be shared is kind of counter intuitive to me. Not really. If you install a particular program that doesn't come with the OS on one

Re: [HACKERS] location of the configuration files

2003-02-18 Thread Bruce Momjian
I have a new idea. You know how we have search_path where you can specify multiple schema names. What if we allow the config_dirs/-C to specify multiple directories to search for config files. That way, we can use only one variable, and we can allow people to place different config files in

Re: [HACKERS] location of the configuration files

2003-02-17 Thread Tom Lane
Kevin Brown [EMAIL PROTECTED] writes: Is it possible for the database engine to properly deal with a database when it is told to use a different database encoding than the one the database was initdb'd with? It can't be told to use a different database encoding. However, the default *client*

Re: [HACKERS] location of the configuration files

2003-02-17 Thread Andrew Sullivan
On Fri, Feb 14, 2003 at 10:35:41AM -0500, Tom Lane wrote: FHS or no FHS, I would think that the preferred arrangement would be to keep Postgres' config files in a postgres-owned subdirectory, not directly in /etc. That way you need not be root to edit them. (My idea Besides, what are you

Re: [HACKERS] location of the configuration files

2003-02-17 Thread Andrew Sullivan
On Sun, Feb 16, 2003 at 12:16:44AM -0500, Tom Lane wrote: Nor will I buy an argument that only a few developers have need for test installations. Ordinary users will want to do that anytime they are doing preliminary tests on a new PG version before migrating their production database to it.

Re: [HACKERS] location of the configuration files

2003-02-16 Thread Peter Eisentraut
Tom Lane writes: AFAICS, you can either set -C to /etc if you want your PG config files loose in /etc, or you can set it to /etc/postgresql/ if you want them in a privately-owned directory. Which other arrangements are needed? People might want to share them between servers, or allow a user

Re: [HACKERS] location of the configuration files

2003-02-16 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: AFAICS, you can either set -C to /etc if you want your PG config files loose in /etc, or you can set it to /etc/postgresql/ if you want them in a privately-owned directory. Which other arrangements are needed? People might want to

Re: [HACKERS] location of the configuration files

2003-02-16 Thread Tom Lane
Lamar Owen [EMAIL PROTECTED] writes: The script's been out there for awhile. It does some things well, and some things not so well. The config files are still coresident with the database, and backup is more difficult than it can be. Meeting all these needs (with configure switches,

Re: [HACKERS] location of the configuration files

2003-02-16 Thread Tom Lane
Kevin Brown [EMAIL PROTECTED] writes: So in your case, what's the advantage of having initdb write anything to a config file, when you're probably also relying on PGDATA or -D to start the database (if you're not, then fair enough. But see below)? Keep in mind that initdb doesn't currently

Re: [HACKERS] location of the configuration files

2003-02-16 Thread Lamar Owen
On Sunday 16 February 2003 13:15, Tom Lane wrote: Sure. I'm happy to change the software in a way that *allows* moving the config files elsewhere. So we agree. Perfect. But it's not apparent to me why you insist on forcing people who are perfectly happy with their existing configuration

Re: [HACKERS] location of the configuration files

2003-02-16 Thread mlw
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: I would favor a setup that allows a -C *directory* (not file) to be specified as a postmaster parameter separately from the -D directory; A directory is not going to satisfy people. Why not?

Re: [HACKERS] location of the configuration files

2003-02-16 Thread Tom Lane
mlw [EMAIL PROTECTED] writes: The idea of using a directory puts us back to using symlinks to share files. So? If you want to share files, you're probably sharing all three config files and don't need a separate directory at all. This is not a sufficient argument to make me buy into the mess

Re: [HACKERS] location of the configuration files

2003-02-16 Thread Kevin Brown
Tom Lane wrote: Keep in mind that initdb doesn't currently *need* to put the datadir location into the config file. It *will* need to do so if we separate config and data dirs. Or at least, *somebody* will need to do so. It's not apparent to me how it simplifies life not to have initdb do

Re: [HACKERS] location of the configuration files

2003-02-16 Thread Kevin Brown
mlw wrote: symlinks suck. Sorry Tom, but they are *BAD* in a production server. Well, at least they're better than hard links. ;-) -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you

Re: [HACKERS] location of the configuration files

2003-02-16 Thread mlw
Tom Lane wrote: mlw [EMAIL PROTECTED] writes: The idea of using a directory puts us back to using symlinks to share files. So? If you want to share files, you're probably sharing all three config files and don't need a separate directory at all. This is not a sufficient argument to

Re: [HACKERS] location of the configuration files

2003-02-15 Thread mlw
Martin Coxall wrote: On Thu, 2003-02-13 at 20:28, Steve Crawford wrote: I don't see why we can't keep everyone happy and let the users choose the setup they want. To wit, make the following, probably simple, changes: 1) Have postgresql default to using /etc/postgresql.conf

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Lamar Owen
On Friday 14 February 2003 11:02, Shridhar Daithankar wrote: Especially the whole discussion of PGDATA stuff fails to register as significant IMO. Right now, I can do things the way I want to do and I guess it is pretty much same with everyone else. Is it last topic left to improve? If it

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Kevin Brown
Tom Lane wrote: Currently, I don't need to do anything more than set PGDATA or say -D to initdb in order to set up the data directory wherever I like. I also don't need to worry about whether I'm selecting the wrong config file. So in your case, what's the advantage of having initdb write

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Lamar Owen
On Friday 14 February 2003 15:10, Tom Lane wrote: I don't see why we don't just let initdb install suggested config files into the new $PGDATA directory, same as it ever did. Ok, let me take another tack. Just exactly why does initdb need to drop any config files anywhere? We provide

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Tom Lane
Lamar Owen [EMAIL PROTECTED] writes: Just exactly why does initdb need to drop any config files anywhere? Because we'd like it to edit the correct datadir into the config file, to take just the most obvious example. There has also been a great deal of discussion recently about other things

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Lamar Owen
On Saturday 15 February 2003 20:19, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: Just exactly why does initdb need to drop any config files anywhere? Because we'd like it to edit the correct datadir into the config file, to take just the most obvious example. Shouldn't we be

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Tom Lane
Lamar Owen [EMAIL PROTECTED] writes: On Saturday 15 February 2003 20:19, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: Just exactly why does initdb need to drop any config files anywhere? Because we'd like it to edit the correct datadir into the config file, to take just the most

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Robert Treat
On Saturday 15 February 2003 09:48 am, mlw wrote: Robert Treat wrote: Seems like some are saying one of the problems with the current system is it doesn't follow FHS or LSB. If those are valid reasons to change the system, it seems like a change which doesn't actually address those concerns

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Lamar Owen
On Saturday 15 February 2003 21:06, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: Shouldn't we be consistent and have initdb use the datadir set in the config file, which could be supplied by a ./configure switch? That'd mean there is no way to perform an initdb into a nonstandard

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Tom Lane
Lamar Owen [EMAIL PROTECTED] writes: I realize that from a packager's point of view, the separate initdb step is not very useful. But it is from my point of view. Would you mind elucidating which point of view is yours? Primarily, one that wants to have multiple postmasters running, of the

Re: [HACKERS] location of the configuration files

2003-02-15 Thread Lamar Owen
On Sunday 16 February 2003 00:16, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: Would you mind elucidating which point of view is yours? Primarily, one that wants to have multiple postmasters running, of the same or different versions; including test and temporary installations that

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Tom Lane wrote: Kevin Brown [EMAIL PROTECTED] writes: I agree with your assessment for the most part, except for PGDATA. There's no good reason I can think of for the postmaster to look at it. The other side of that coin is, what's the good reason to remove it? There's a long way

Re: [MLIST] Re: [HACKERS] location of the configuration files

2003-02-14 Thread David Walker
In reference to determining what port postgres or any program is listening on On my Redhat Linux machines netstat --inet -nlp when run as root produces a nice list of all programs listening on the network with IP and port number the process is listening on, the name of the process and the pid.

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: If you want ps to display the data dir, you should use -D. Remember, it is mostly important for multiple postmaster, so if you are doing that, just use -D, but don't prevent single-postmaster folks from using PGDATA. Perhaps the best compromise would be to change pg_ctl

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: If you want ps to display the data dir, you should use -D. Remember, it is mostly important for multiple postmaster, so if you are doing that, just use -D, but don't prevent single-postmaster folks from using PGDATA. Perhaps another reasonable approach would be to put an

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Martin Coxall
If you are interested in reading a contrary position, you can read Berstein's arguments for his recommended way to install services at: http://cr.yp.to/unix.html But since DJB is a class-A monomaniac, he may not be the best person to listen to. /var/qmail/control for qmail configuration

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Martin Coxall
Generally things that live in /etc are owned and operated by the OS. Postgresql, by it's definition is a userspace program, not an OS owned one. Partially true. The FHS specifies that the /etc top layer is for system-own3d stuff, but the subdirectories off it are explicitly used for user

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Martin Coxall
On Thu, 2003-02-13 at 20:28, Steve Crawford wrote: I don't see why we can't keep everyone happy and let the users choose the setup they want. To wit, make the following, probably simple, changes: 1) Have postgresql default to using /etc/postgresql.conf /etc/postgres/postgresql.conf, if we

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: I just set PGDATA in my login and I don't have to deal with it again. Hmm...you don't use pg_ctl to start/stop/whatever the database? You invoke the postmaster directly (I can easily see that you would, just asking if you do)? -- Kevin Brown

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: I just set PGDATA in my login and I don't have to deal with it again. DuhI just realized a reason you guys might care about this so much. It's because you want to be able to start the postmaster from within a debugger (or profiler, or whatever), and you don't want to

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Vince Vielhaber
On 14 Feb 2003, Martin Coxall wrote: If you are interested in reading a contrary position, you can read Berstein's arguments for his recommended way to install services at: http://cr.yp.to/unix.html But since DJB is a class-A monomaniac, he may not be the best person to listen to.

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Martin Coxall
On Fri, 2003-02-14 at 14:21, Vince Vielhaber wrote: On 14 Feb 2003, Martin Coxall wrote: If you are interested in reading a contrary position, you can read Berstein's arguments for his recommended way to install services at: http://cr.yp.to/unix.html But since DJB is a class-A

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: OK, here is an updated proposal. I think we have decided: Moving postmaster.pid and postmaster.opts isn't worth it. We don't want per-file GUC variables, but assume it is in the same config directory as postgresql.conf. I don't see any valid

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: Give it up. As long as we have -D, we will allow PGDATA. If you don't want to use it, don't use it. Agreed. I'm not sure I see how this diminishes the argument for fixing pg_ctl so that it passes an explicit -D option to the postmaster when invoking it... -- Kevin

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: This way, people who start the database using the standard tools we supply will know exactly what's going on when they get a ps listing. No. If you want ps to display, don't use environment variables. Many don't care --- especially those with only one postmaster. You

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Tom Lane
Kevin Brown [EMAIL PROTECTED] writes: Tom Lane wrote: The other side of that coin is, what's the good reason to remove it? There's a long way between I don't want my setup to depend on PGDATA and I don't think your setup should be allowed to depend on PGDATA. If you don't want to use it, then

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Vince Vielhaber
On 14 Feb 2003, Martin Coxall wrote: On Fri, 2003-02-14 at 14:21, Vince Vielhaber wrote: On 14 Feb 2003, Martin Coxall wrote: If you are interested in reading a contrary position, you can read Berstein's arguments for his recommended way to install services at:

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Tom Lane wrote: I am happy to design an arrangement that allows you not to depend on PGDATA if you don't want to. But I don't see why you need to break my configuration procedures in order to fix yours. As I outlined last night, it's possible to do what you want without breaking backwards

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Tom Lane
Kevin Brown [EMAIL PROTECTED] writes: I'm quite interested in knowing why there seems to be so much resistance to removing the potential_DataDir = getenv(PGDATA); line from postmaster.c. Backwards compatibility. Also, you still haven't explained why I don't want to use PGDATA should translate

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Tom Lane
Martin Coxall [EMAIL PROTECTED] writes: Partially true. The FHS specifies that the /etc top layer is for system-own3d stuff, but the subdirectories off it are explicitly used for user space programs and, well, everything. (/etc/apache, /etc/postgres, /etc/tomcat3, /etc/tomcat4...) FHS or no

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Robert Treat
On Thu, 2003-02-13 at 19:22, Adam Haberlach wrote: On Thu, Feb 13, 2003 at 05:59:17PM -0500, Robert Treat wrote: On Thu, 2003-02-13 at 15:08, mlw wrote: Stephan Szabo wrote: On Thu, 13 Feb 2003, mlw wrote: Personally I think a postgresql installation is much more like an apache

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: My point is that folks with multiple postmasters may not want to use PGDATA, but for folks who have single postmasters, it makes things easier and less error-prone. Actually, for multi postmasters too. I have little shell-environment config files that

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Shridhar Daithankar[EMAIL PROTECTED]
On Friday 14 Feb 2003 9:05 pm, you wrote: Martin Coxall [EMAIL PROTECTED] writes: Here's a pretty topic for a flamewar: should it be /etc/postgres/ or /etc/postgresql/ ? I vote for /etc/pgsql. Keeping in line of unix philosophy of cryptic and short names. Who wants a descriptive names

Re: [HACKERS] location of the configuration files

2003-02-14 Thread scott.marlowe
On Thu, 13 Feb 2003, mlw wrote: scott.marlowe wrote: These are not issues at all. You could put the configuration file anywhere, just as you can for any UNIX service. postmaster --config=/home/myhome/mydb.conf I deal with a number of PG databases on a number of sites, and it is a

Re: [HACKERS] location of the configuration files

2003-02-14 Thread scott.marlowe
On Fri, 14 Feb 2003, Curt Sampson wrote: On Thu, 13 Feb 2003, scott.marlowe wrote: If I do a .tar.gz install of apache, I get /usr/local/apache/conf, which is not the standard way you're listing. I'm going to stay out of this argument from now on, but this struck a sore point. /usr

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: The big question is whether PGDATA is still our driving config variable, and PGCONFIG/-C is just an additional option, or whether we are moving in a direction where PGCONFIG/-C is going to be the driving value, and data_dir is going to be read as part of that. I'm

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruno Wolff III
On Thu, Feb 13, 2003 at 11:53:26 -0500, mlw [EMAIL PROTECTED] wrote: Where, specificaly are his arguements against a configuration file methodology? I don't think he is argueing against a configuration methodology, but rather against the methodology being used in Unix distributions. In

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Greg Stark
scott.marlowe [EMAIL PROTECTED] writes: But this isn't the same thing at all. Apache, when built from a tar ball, goes into /usr/local/apache/ and ALL it's configuration files are there. Two comments: 1) Even in that case the config files go into /usr/local/apache/conf and the other

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruno Wolff III
On Fri, Feb 14, 2003 at 02:58:49 -0800, Kevin Brown [EMAIL PROTECTED] wrote: Lest you think that this is an unlikely scenario, keep in mind that most startup scripts, including pg_ctl, currently start the postmaster without arguments and rely on PGDATA, so a shop that hasn't already been

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: I see your point --- pg_ctl does a PGDATA trick when passed -D: -D) shift # pass environment into new postmaster PGDATA=$1 export PGDATA It should pass -D just like it was given. Yes, exactly. Now, the more

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Steve Crawford
On Friday 14 February 2003 6:07 am, Martin Coxall wrote: On Thu, 2003-02-13 at 20:28, Steve Crawford wrote: I don't see why we can't keep everyone happy and let the users choose the setup they want. To wit, make the following, probably simple, changes: 1) Have postgresql default to using

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
I don't want to over-engineer this. Propogating -D into postmaster makes sense, but grabbing PGDATA doesn't to me. --- Kevin Brown wrote: Bruce Momjian wrote: I see your point --- pg_ctl does a PGDATA trick when passed

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Curt Sampson
On Fri, 14 Feb 2003, scott.marlowe wrote: Asking for everything in a directory with the name local in it to be shared is kind of counter intuitive to me. Not really. If you install a particular program that doesn't come with the OS on one machine on your site, why would you not want to install

Re: [HACKERS] Location of the configuration files, round 2

2003-02-14 Thread mlw
One of the things that I HATE about this discussion is that everyone wants to put limits on configurability. I am an old fashion UNIX guy, capability without enforcing policy! Adding an ability is different than enforcing a policy. All I any to do is add the capability of configuration in a

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Peter Eisentraut wrote: Tom Lane writes: I would favor a setup that allows a -C *directory* (not file) to be specified as a postmaster parameter separately from the -D directory; A directory is not going to satisfy people. Who is asking to put postgresql.conf, pg_hba.conf, and

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: I would favor a setup that allows a -C *directory* (not file) to be specified as a postmaster parameter separately from the -D directory; A directory is not going to satisfy people. Why not? Who won't it satisfy, and what's their

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Peter Eisentraut
Tom Lane writes: I would favor a setup that allows a -C *directory* (not file) to be specified as a postmaster parameter separately from the -D directory; A directory is not going to satisfy people. I don't see any great value in a separate postgresql.conf parameter for each secondary

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think the big question is whether we want the default to install the configs in a separate directory, pgsql/etc, or just allow the specification of a separate location. Advantages of pgsql/etc are initdb-safe, and easier backups.

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Oliver Elphick
On Fri, 2003-02-14 at 15:35, Tom Lane wrote: Here's a pretty topic for a flamewar: should it be /etc/postgres/ or /etc/postgresql/ ? It should be configurable! Debian uses /etc/postgresql, if you want to stick to what quite a lot of people are familiar with. -- Oliver Elphick

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Kevin Brown wrote: Tom Lane wrote: Kevin Brown [EMAIL PROTECTED] writes: I agree with your assessment for the most part, except for PGDATA. There's no good reason I can think of for the postmaster to look at it. The other side of that coin is, what's the good reason to remove it?

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
OK, here is an updated proposal. I think we have decided: Moving postmaster.pid and postmaster.opts isn't worth it. We don't want per-file GUC variables, but assume it is in the same config directory as postgresql.conf. I don't see any valid reason they would

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Oliver Elphick
On Fri, 2003-02-14 at 12:17, Bruce Momjian wrote: If you want ps to display the data dir, you should use -D. Remember, it is mostly important for multiple postmaster, so if you are doing that, just use -D, but don't prevent single-postmaster folks from using PGDATA. Could not the ps line be

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
I am not sure if it is a good idea to be mucking with it. For backend, we do the entire thing, so it is clear we modified something. --- Oliver Elphick wrote: On Fri, 2003-02-14 at 12:17, Bruce Momjian wrote: If you

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Kevin Brown wrote: Bruce Momjian wrote: If you want ps to display the data dir, you should use -D. Remember, it is mostly important for multiple postmaster, so if you are doing that, just use -D, but don't prevent single-postmaster folks from using PGDATA. Perhaps the best compromise

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Kevin Brown wrote: Bruce Momjian wrote: I just set PGDATA in my login and I don't have to deal with it again. Hmm...you don't use pg_ctl to start/stop/whatever the database? You invoke the postmaster directly (I can easily see that you would, just asking if you do)? I can use either to

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Give it up. As long as we have -D, we will allow PGDATA. If you don't want to use it, don't use it. --- Kevin Brown wrote: Bruce Momjian wrote: I just set PGDATA in my login and I don't have to deal with it again.

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
My point is that folks with multiple postmasters may not want to use PGDATA, but for folks who have single postmasters, it makes things easier and less error-prone. --- Bruce Momjian wrote: Give it up. As long as we

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Kevin Brown wrote: Bruce Momjian wrote: OK, here is an updated proposal. I think we have decided: Moving postmaster.pid and postmaster.opts isn't worth it. We don't want per-file GUC variables, but assume it is in the same config directory as postgresql.conf. I don't

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: So, we add data_dir to postgresql.conf, and add -C/PGCONFIG to postmaster. Wait one second. You are blithely throwing in a PGCONFIG variable without any detailed proposal of exactly how it will work. Does that override a PGDATA environment variable?

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Tom Lane
Oliver Elphick [EMAIL PROTECTED] writes: On Fri, 2003-02-14 at 12:17, Bruce Momjian wrote: If you want ps to display the data dir, you should use -D. Remember, it is mostly important for multiple postmaster, so if you are doing that, just use -D, but don't prevent single-postmaster folks from

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: So, we add data_dir to postgresql.conf, and add -C/PGCONFIG to postmaster. Wait one second. You are blithely throwing in a PGCONFIG variable without any detailed proposal of exactly how it will work. Does that override a PGDATA

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Kevin Brown wrote: Bruce Momjian wrote: The big question is whether PGDATA is still our driving config variable, and PGCONFIG/-C is just an additional option, or whether we are moving in a direction where PGCONFIG/-C is going to be the driving value, and data_dir is going to be read as

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I think the big question is whether we want the default to install the configs in a separate directory, pgsql/etc, or just allow the specification of a separate location. Advantages of pgsql/etc are initdb-safe, and easier backups. I don't see why we

Re: [HACKERS] location of the configuration files

2003-02-14 Thread Bruce Momjian
Kevin Brown wrote: Bruce Momjian wrote: The big question is whether PGDATA is still our driving config variable, and PGCONFIG/-C is just an additional option, or whether we are moving in a direction where PGCONFIG/-C is going to be the driving value, and data_dir is going to be read as

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Martin Coxall
Well, to the extent that you're serious, you understand that a lot of people feel that /usr/local should be reserved for stuff that's installed by the local sysadmin, and your vendor/distro isn't supposed to be messing with it. Which means if the the vendor installed Postgresql (say,

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Curt Sampson
On Wed, 12 Feb 2003, Peter Bierman wrote: What do you gain by having the postmaster config and the database data live in different locations? You can then standardize a location for the configuration files. Everybody has room in /etc for another 10K of data. Where you have room for something

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Christopher Browne
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote: On Wed, 12 Feb 2003, Peter Bierman wrote: What do you gain by having the postmaster config and the database data live in different locations? You can then standardize a location for the configuration files. Everybody has

Re: [HACKERS] location of the configuration files

2003-02-13 Thread mlw
Christopher Browne wrote: In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote: On Wed, 12 Feb 2003, Peter Bierman wrote: What do you gain by having the postmaster config and the database data live in different locations? You can

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Curt Sampson
On Thu, 13 Feb 2003, Christopher Browne wrote: 1. It assumes that there is a location for the configuration files for /the single database instance./ No; it assumes that there's a location for the default instance. If you have more than one, you could have one default and one elsewhere,

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Lamar Owen
On Thursday 13 February 2003 08:32, Christopher Browne wrote: In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote: Everybody has room in /etc for another 10K of data. Where you have room for something that might potentially be a half terrabyte of data, and is not

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Nigel J. Andrews
On Thu, 13 Feb 2003, Curt Sampson wrote: On Thu, 13 Feb 2003, Christopher Browne wrote: 1. It assumes that there is a location for the configuration files for /the single database instance./ No; it assumes that there's a location for the default instance. If you have more than

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Bruno Wolff III
On Thu, Feb 13, 2003 at 15:03:09 +, Nigel J. Andrews [EMAIL PROTECTED] wrote: Is everyone forgetting that wherever the configuration file is stored and whether or not it needs a command line argument to specify it the database is not going to start up automatically unless at least part

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Bruno Wolff III
On Thu, Feb 13, 2003 at 09:23:20 -0500, mlw [EMAIL PROTECTED] wrote: Personally, however, I think the configuration issue is a no-brainer and I am amazed that people are balking. EVERY other service on a UNIX box is configured in this way, why not do it this way in PostgreSQL? The patch

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Robert Treat
On Thu, 2003-02-13 at 09:23, mlw wrote: I deal with a number of PG databases on a number of sites, and it is a real pain in the ass to get to a PG box and hunt around for data directory so as to be able to administer the system. What's really annoying is when you have to find the data

Re: [HACKERS] location of the configuration files

2003-02-13 Thread mlw
Robert Treat wrote: On Thu, 2003-02-13 at 09:23, mlw wrote: I deal with a number of PG databases on a number of sites, and it is a real pain in the ass to get to a PG box and hunt around for data directory so as to be able to administer the system. What's really annoying is

Re: [HACKERS] location of the configuration files

2003-02-13 Thread mlw
Bruno Wolff III wrote: On Thu, Feb 13, 2003 at 09:23:20 -0500, mlw [EMAIL PROTECTED] wrote: Personally, however, I think the configuration issue is a no-brainer and I am amazed that people are balking. EVERY other service on a UNIX box is configured in this way, why not do

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Stephan Szabo
On Thu, 13 Feb 2003, mlw wrote: Robert Treat wrote: On Thu, 2003-02-13 at 09:23, mlw wrote: I deal with a number of PG databases on a number of sites, and it is a real pain in the ass to get to a PG box and hunt around for data directory so as to be able to administer the system.

Re: [HACKERS] location of the configuration files

2003-02-13 Thread mlw
Stephan Szabo wrote: On Thu, 13 Feb 2003, mlw wrote: Robert Treat wrote: On Thu, 2003-02-13 at 09:23, mlw wrote: I deal with a number of PG databases on a number of sites, and it is a real pain in the ass to get to a PG box and hunt

Re: [HACKERS] location of the configuration files

2003-02-13 Thread Stephan Szabo
On Thu, 13 Feb 2003, mlw wrote: Stephan Szabo wrote: On Thu, 2003-02-13 at 09:23, mlw wrote: I deal with a number of PG databases on a number of sites, and it is a real pain in the ass to get to a PG box and hunt around for data directory so as to be able to administer the system. What's

  1   2   >