Bruce Momjian wrote:
I don't think separate params for each config file is good. At the
most, I think we will specify the configuration _directory_ for all the
config files, perhaps pgsql/etc, and have pgdata default to ../data, or
honor $PGDATA. That might be the cleanest.
Of course,
Vince Vielhaber wrote:
On Thu, 13 Feb 2003, Lamar Owen wrote:
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
Actually FHS says the opposite. If the distribution installs PostgreSQL
then the config files belong in /etc/postgresql. If the admin does then
they belong in
Tom Lane wrote:
I don't see any great value in a separate postgresql.conf parameter for
each secondary config file; that just means clutter to me, especially
if we add more such files in future. I am also distinctly not in favor
of eliminating the PGDATA environment variable; that reads to me
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 between I don't want my setup
Apache explicitly supports a number of different layouts for files out of
the box (and provides support for you to roll your own very easily). From
the manual:
The second, and more flexible way to configure the install path locations
for Apache is using the config.layout file. Using this method,
On Thursday 13 February 2003 21:13, Bruce Momjian wrote:
Lamar Owen wrote:
It isn't without precedent to have a directory under /var/run. Maybe
/var/run/postgresql. Under this one could have a uniquely named pid
file.
But how do you handle the default then, where you have postmaster.pid
Oliver Elphick [EMAIL PROTECTED] writes:
I'm not entirely sure why SE Linux has a problem, seeing that postgres
needs read-write access to all the files in $PGDATA, but assuming the
need is verified, I could do this by moving the pid file from
$PGDATA/postmaster.pid to
On Thursday 13 February 2003 21:49, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
need is verified, I could do this by moving the pid file from
$PGDATA/postmaster.pid to /var/run/postgresql/5432.pid and similarly for
other ports. This would also have the benefit of being more
Lamar Owen wrote:
I am now wondering if we even want pg_hba_dir and pg_ident_dir. Seems
we can assume they are in the same directory as postgresql.conf. That
leaves only data_dir as new for postgresql.conf.
Ok, if we're going this far already, tell me exactly why we have three config
Lamar Owen [EMAIL PROTECTED] writes:
Ok, if we're going this far already, tell me exactly why we have three config
files. Why not really Unify things and fulfil the full promise of Grand
Unified Configuration by rolling hba and ident into postgresql.conf. Is
there a compelling reason not
On Thu, 2003-02-13 at 23:06, mlw wrote:
Bruce Momjian wrote:
Can non-root write to /var/run?
Shouldn't be able too
But it should be able to write under /var/run/postgresql, which the
distribution will set up with the correct permissions.
--
Oliver Elphick
On Thu, 2003-02-13 at 22:53, Bruce Momjian wrote:
Oliver Elphick wrote:
What your comments strongly suggest to me is that projects like
PostgreSQL and pine, along with everything else, should comply with FHS;
then there will be no confusion because everyone will be following the
smae
On Fri, 2003-02-14 at 02:49, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
I'm not entirely sure why SE Linux has a problem, seeing that postgres
needs read-write access to all the files in $PGDATA, but assuming the
need is verified, I could do this by moving the pid file from
On Fri, 2003-02-14 at 02:45, [EMAIL PROTECTED] wrote:
3.7.1 Purpose
/etc contains configuration files and directories that are specific to the
current system.
3.7.4 Indicates that
Host-specific configuration files for add-on application software packages
must be installed within the
All I see here is an arbitrary break with our past practice. I do
not see any net improvement.
FreeBSD Port Maintainer
Well, given that there's a trend to make PostgreSQL more usable, I can
say with absolute certainty, that an FAQ that I get about once a week
is (and granted only from new
On Thu, 2003-02-13 at 21:21, Vince Vielhaber wrote:
I certainly wasn't trying to provoke anything. It just seems odd to me
that when the distribution installs a package and places it's config files
in /etc and later the admin happens to upgrade by the instructions with
the package, it's
On Thu, 2003-02-13 at 14:28, Bruce Momjian wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 14:06, mlw wrote:
I will be resubmitting my patch for the 7.3.2 tree.
I'm no core developer, but surely this wont be included in the 7.3.x
branch. Any change needs to be made against
On Thu, 2003-02-13 at 14:43, Bruce Momjian wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file
On Thu, 2003-02-13 at 14:51, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
Oliver Elphick wrote:
What your comments strongly suggest to me is that projects like
PostgreSQL and pine, along with everything else, should comply with FHS;
then there will be no confusion because everyone will be following the
smae standards. Messes arise when people ignore standards; we
Robert Treat wrote:
IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
not sure about postmaster.opts though...
Again, if we're going to make a change, let's make sure we think it
through.
Can non-root write to /var/run?
--
Bruce Momjian|
Bruce Momjian wrote:
Robert Treat wrote:
IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
not sure about postmaster.opts though...
Again, if we're going to make a change, let's make sure we think it
through.
Can non-root write to /var/run?
On 13 Feb 2003, Oliver Elphick wrote:
What your comments strongly suggest to me is that projects like
PostgreSQL and pine, along with everything else, should comply with FHS;
then there will be no confusion because everyone will be following the
smae standards. Messes arise when people
Robert Treat wrote:
On Thu, 2003-02-13 at 14:51, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra
On Thursday 13 February 2003 17:53, Bruce Momjian wrote:
Oliver Elphick wrote:
What your comments strongly suggest to me is that projects like
PostgreSQL and pine, along with everything else, should comply with FHS;
then there will be no confusion because everyone will be following the
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
Actually FHS says the opposite. If the distribution installs PostgreSQL
then the config files belong in /etc/postgresql. If the admin does then
they belong in /usr/local/etc/postgresql. FHS is out of their tree. If
PostgreSQL or
On Thu, 13 Feb 2003, Lamar Owen wrote:
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
Actually FHS says the opposite. If the distribution installs PostgreSQL
then the config files belong in /etc/postgresql. If the admin does then
they belong in /usr/local/etc/postgresql. FHS
On Thursday 13 February 2003 18:41, Vince Vielhaber wrote:
On Thu, 13 Feb 2003, Lamar Owen wrote:
PostgreSQL is as critical as PHP, Apache, or whatever other package is
being backended by PostgreSQL. If the package is provided by the
distributor, consider it part of the OS. If it isn't,
On Thu, 2003-02-13 at 13:32, Christopher Browne 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 infrequently several gigabytes or more, is pretty
system-depenendent.
Ah, but this
On Thu, 2003-02-13 at 12:00, Vince Vielhaber wrote:
Which means if the the vendor installed Postgresql (say, the
Red Hat Database) you'd expect config files to be in /etc.
If the postgresql is compiled from source by local admin,
you might look somewhere in /usr/local.
Then why not
On 13 Feb 2003, Oliver Elphick wrote:
On Thu, 2003-02-13 at 12:00, Vince Vielhaber wrote:
Which means if the the vendor installed Postgresql (say, the
Red Hat Database) you'd expect config files to be in /etc.
If the postgresql is compiled from source by local admin,
you might look
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 build for distributions are
making an ill advised change. Simply because the distribution makes the
decision to add
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 build for distributions are
making an ill advised change. Simply because the distribution makes the
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 build for distributions are
making an ill advised
On Thu, 2003-02-13 at 18:45, Bruce Momjian wrote:
Now, on to this configuration discussion. Seems moving the config file
out of $PGDATA requies either:
1) we specifiy both the config directory and the data directory on
postmaster start
2) we specify the
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 build for distributions are
making an ill
mlw wrote:
It doesn't have anything to do with not-invented-here, which is a
common refrain by people who don't like our decisions, like Why don't
you use mmap()? Oh, it's because I thought of it and you didn't. Does
anyone seriously believe that is the motiviation of anyone in this
Robert Treat wrote:
On Thu, 2003-02-13 at 14:06, mlw wrote:
I will be resubmitting my patch for the 7.3.2 tree.
I'm no core developer, but surely this wont be included in the 7.3.x
branch. Any change needs to be made against CVS head.
I assume he meant he will repost his 7.3.2-based
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile= '/etc/postgres/pg_hba.conf'
identfile='/etc/postgres/pg_ident.conf'
On Wed, 12 Feb 2003, J. M. Brenner wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
directories with /etc as the root of the hierarchy.
-Original Message-
From: Christopher Browne [mailto:[EMAIL PROTECTED]]
Sent: 13 February 2003 13:33
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] location of the configuration files
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
On Wed, 12 Feb 2003
mlw [EMAIL PROTECTED] writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running on a single machine. This is not unrelated.
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running
On Thursday 13 February 2003 10:03, Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running
Bruce Momjian wrote:
Well, in a sense, it trades passing one parameter, PGDATA, for another.
I see your point that we should specify configuration first, and let
everything pass from there. However, it does add extra configuration
parameters, and because you still need to specify/create
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile= '/etc/postgres/pg_hba.conf'
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile= '/etc/postgres/pg_hba.conf'
On Thu, 2003-02-13 at 19:30, Robert Treat wrote:
If we're going to do this, I think we need to account for all of the
files in the directory including PG_VERSION, postmaster.opts,
Not PG_VERSION; that is intimately associated with the data itself and
ought to stay in the data directory.
--
mlw writes:
AFAIK it wasn't actually done. It was more of a, we should do something
different argument. At one point it was talked about rewriting the
configuration system to allow include and other things.
The core of the problem was, and continues to be, this: If you move
postgresql.conf
Peter Eisentraut wrote:
mlw writes:
AFAIK it wasn't actually done. It was more of a, "we should do something
different" argument. At one point it was talked about rewriting the
configuration system to allow "include" and other things.
The core of the problem was, and
Lamar Owen wrote:
This isn't the same environment, Bruce, that you got into back when it was
still Postgres95. We are in the big leagues OS-wise, and we need to act like
it. Assuming that we are a 'userspace' program (which is a misnomer anyway,
as _anything_ non-kernel is 'userspace') is
On Thursday 13 February 2003 20:09, Bruce Momjian wrote:
Lamar Owen wrote:
This isn't the same environment, Bruce, that you got into back when it
was still Postgres95.
So you are saying this isn't my grandma's database anymore. :-)
I actually thought of saying it that way, too. :-)
Lamar Owen wrote:
First, a few conclusions:
We can't use /var/run because we need the postmaster to create
those, and it isn't root.
It isn't without precedent to have a directory under /var/run. Maybe
/var/run/postgresql. Under this one could have a uniquely named pid file.
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf.
Okay, here's one: most Unix systems
On Wed, 2003-02-12 at 08:24, Kevin Brown wrote:
Tom Lane wrote:
You can only justify it as simpler if you propose hardwiring a value
for $SOMECONFIGDIRECTORY ...
Making things simpler from the standpoint of the code isn't the point.
Making things simpler for the DBA and/or Unix sysadmin
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
directories with /etc as the root of the hierarchy. When an
administrator is looking for configuration files, the first place he's
going to look is in
binaries (he doesn't necessarily have access to the sources that the
binaries were compiled from, which is all that matters here).
No goddammit - /usr/local/etc. Why can't the Linux community respect
history
History? It's the only way to make a read-only / (enforced by
secure-level)
On Wednesday 12 February 2003 20:37, Christopher Kings-Lynne wrote:
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
No [snip] - /usr/local/etc. Why can't the Linux community respect
history
It
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines
the database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the right way to do it.
Isn't the database
Peter Bierman wrote:
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the right way to do it.
Before I get started, I should note that it may be a good compromise
to have the data directory be the same as the config file directory,
when neither the config file nor the command line specify something
different. So the changes I think may make the most sense are:
1. We add a new GUC
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
directories with /etc as the root of the hierarchy. When an
administrator is looking for
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf. The latter keeps
mlw [EMAIL PROTECTED] writes:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the right way to do it.
I guess I'm just dense, but
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do
On Tue, 2003-02-11 at 13:44, mlw wrote:
The debate on the configuration file sparked a memory of an old patch I
submitted in 7.1 days.
One of the things I do not like about PostgreSQL is, IMHO, is a
backwards configuration process. Rather than specify a data directory,
the administrator
Robert Treat wrote:
I'm going to be lazy and ask if you can post what the better solution
that was coming was (or a link to the thread). While I'll grant you that
the it's coming argument is pretty weak after two releases, that fact
that it may have been a better solution could still hold up.
I, personally, also think it makes more sense to pass to the postmaster
a configuration file that contains all the rest of the information about
the database system, including the disk locations of the various data
directories and whatnot.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737
mlw wrote:
AFAIK it wasn't actually done. It was more of a, we should do something
different argument. At one point it was talked about rewriting the
configuration system to allow include and other things.
That seems like extreme overkill. The PostgreSQL configuration
mechanism doesn't seem
Kevin Brown [EMAIL PROTECTED] writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf. The latter keeps all the related files
together. The former
101 - 171 of 171 matches
Mail list logo
