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
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
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
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
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
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
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*
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
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.
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
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
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,
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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?
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
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
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
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
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
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.
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
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
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?
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
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
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
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
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,
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
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
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
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,
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
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
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
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
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
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
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
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.
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
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
On 13 Feb 2003, Martin Coxall wrote:
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
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
2) Add a setting in postgresql.conf specifying the data directory
3) Change the meaning of -D
On 13 Feb 2003, Oliver Elphick wrote:
On Thu, 2003-02-13 at 18:45, Bruce Momjian wrote:
Oliver Elphick wrote:
On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
Seems to me that if FHS allows such a mess, it's reason enough to avoid
compliance. Either that or those of you who
On Thu, 13 Feb 2003, mlw wrote:
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
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
real pain in the ass to get
On Thu, 2003-02-13 at 15:08, mlw wrote:
Stephan Szabo wrote:
Re-read my statement and yours about the case you were mentioning. ;)
Sure, putting the files in /etc lets you find them easily. However, if
you're doing things like finding configuration made by someone else and
said
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:
I have absolutely no problem debating and augmenting the feature. None
what so ever, I am more pushing to get momentum to
1 - 100 of 173 matches
Mail list logo
