"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 nightmar
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
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 o
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
pe
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 al
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 plac
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 dif
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 on
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 i
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
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 *cl
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: yo
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
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
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
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?
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 configuratio
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 currentl
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,
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
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 use
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 a
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
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
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 nonstan
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
> >co
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 th
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 c
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 in
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
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 templa
mlw <[EMAIL PROTECTED]> wrote:
> I am an old fashion UNIX guy, capability without enforcing policy!
> Adding an ability is different than enforcing a policy.
You can push this too far, though. Every capability that
you add still complicates testing and documentation, even if
very difficult t
mlw <[EMAIL PROTECTED]> writes:
> I would really like to push back this whole discussion to adding the
> ability the flexibility to configure PostgreSQ as opposed to determining
> a specific configuration strategy.
> Adding the ability is easy. Let the distros determine their strategy.
> Trying
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
/etc/postg
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 would not be acceptable. (Unless those really aren't
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 way
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 instal
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 passe
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 re
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
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
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 co
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
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 pg
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 t
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,
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 re
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
>
"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
ot
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
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 actu
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
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.
> I seriously doubt your ability to judge anyone's mental stability.
> I can also see that you prefer cross-platform INcompatibility. Your
> position and mindset are now crystal clear.
Come now- don't take it personally. All I said is, as someone who
wrestles daily with QMail, we should prefer t
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
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 o
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 any
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 th
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 a
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
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
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 fo
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?
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
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:
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 t
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 postmast
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
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:
> 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
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 sin
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 ha
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.
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
> l
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
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 e
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
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 w
> 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 use
> > 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 configurati
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 c
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
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_c
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 w
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
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 wa
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.
Th
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 reas
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
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, i
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 wit
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
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
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
> > s
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
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
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
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 co
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
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 /var/run/postgresql
1 - 100 of 190 matches
Mail list logo
