RedHat startup script and environment variables in 7.1.2?
It looks as though the init.d script "postgres" supplied with
7.1.2 no longer propagates environment variables to pg_ctl. Was that
an intentional change? Or is this something no one else sees?
I put databases off on their own partition, away from /var/lib/pgsql.
In the base, all I had to do was add:
export SOLISDB=.....
into /etc/rc.d/init.d/postgres to use createdb --location SOLISDB
but I just noticed that this isn't working with 7.1.2. Instead, I
have to put the export directly into /usr/bin/pg_ctl - which I'm not
particularly fond of doing.
Thanks!
--
Steve Wampler- SOLIS Project, National Solar Observatory
swampler@noao.edu
Steve Wampler wrote:
It looks as though the init.d script "postgres" supplied with
7.1.2 no longer propagates environment variables to pg_ctl. Was that
an intentional change? Or is this something no one else sees?I put databases off on their own partition, away from /var/lib/pgsql.
In the base, all I had to do was add:
Sigh, "In the *past*,..."
export SOLISDB=.....
into /etc/rc.d/init.d/postgres to use createdb --location SOLISDB
but I just noticed that this isn't working with 7.1.2. Instead, I
have to put the export directly into /usr/bin/pg_ctl - which I'm not
particularly fond of doing.Thanks!
--
Steve Wampler- SOLIS Project, National Solar Observatory
swampler@noao.edu
--
Steve Wampler- SOLIS Project, National Solar Observatory
swampler@noao.edu
Steve Wampler <swampler@noao.edu> writes:
It looks as though the init.d script "postgres" supplied with
7.1.2 no longer propagates environment variables to pg_ctl. Was that
an intentional change? Or is this something no one else sees?
It's an unintentional sideeffect of fixing the "I changed the
postgres' users shell to tcsh and things don't work like they used to"
problem.
--
Trond Eivind Glomsr�d
Red Hat, Inc.
Trond Eivind Glomsr�d wrote:
Steve Wampler <swampler@noao.edu> writes:
It looks as though the init.d script "postgres" supplied with
7.1.2 no longer propagates environment variables to pg_ctl. Was that
an intentional change? Or is this something no one else sees?It's an unintentional sideeffect of fixing the "I changed the
postgres' users shell to tcsh and things don't work like they used to"
problem.
Ah. Thanks!
It seems that it might be nice to have a way to set these "environment
variables" via entries in postgresql.conf? Not that I have a good way
to fit it into the syntax...:
export = "SOLISDB=...."
perhaps? (Or just add a pg_ctl.conf that contains this information:
export SOLISDB=.....
etc.) Alternate database locations seem to be part of the configuration,
since they have to be defined before starting the postmaster - hence the
suggestion(s) to put them into *.conf.
--
Steve Wampler- SOLIS Project, National Solar Observatory
swampler@noao.edu
On Thursday 23 August 2001 11:43, Steve Wampler wrote:
I put databases off on their own partition, away from /var/lib/pgsql.
In the base, all I had to do was add:
export SOLISDB=.....
Ok, what is wrong with making /var/lib/pgsql it's own partition? I do that
myself. On my production server, /var/lib/pgsql is the mount point for
/dev/hdb6.
but I just noticed that this isn't working with 7.1.2. Instead, I
have to put the export directly into /usr/bin/pg_ctl - which I'm not
particularly fond of doing.
And you're fond of editing the initscript that can be upgraded on top of you?
The init.d script should not be edited. Really. There is, however, a
.bash_profile in /var/lib/pgsql that sets environment variables that are
propagated to pg_ctl (IIRC). Edit that, as it won't be overwritten on the
next upgrade.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen wrote:
On Thursday 23 August 2001 11:43, Steve Wampler wrote:
I put databases off on their own partition, away from /var/lib/pgsql.
In the base, all I had to do was add:export SOLISDB=.....
Ok, what is wrong with making /var/lib/pgsql it's own partition? I do that
myself. On my production server, /var/lib/pgsql is the mount point for
/dev/hdb6.
Because (for whatever reason) some, but not all, of the databases should to be
isolated in the 2nd partition.
but I just noticed that this isn't working with 7.1.2. Instead, I
have to put the export directly into /usr/bin/pg_ctl - which I'm not
particularly fond of doing.And you're fond of editing the initscript that can be upgraded on top of you?
Good point! But I did view it as better than editing /usr/bin/pg_ctl...
The init.d script should not be edited. Really. There is, however, a
.bash_profile in /var/lib/pgsql that sets environment variables that are
propagated to pg_ctl (IIRC). Edit that, as it won't be overwritten on the
next upgrade.
Ah - didn't know about that. That's nicer, thanks!
--
Steve Wampler- SOLIS Project, National Solar Observatory
swampler@noao.edu
Steve Wampler <swampler@noao.edu> writes:
It seems that it might be nice to have a way to set these "environment
variables" via entries in postgresql.conf? Not that I have a good way
to fit it into the syntax...:
export = "SOLISDB=...."
perhaps? (Or just add a pg_ctl.conf that contains this information:
export SOLISDB=.....
etc.) Alternate database locations seem to be part of the configuration,
since they have to be defined before starting the postmaster - hence the
suggestion(s) to put them into *.conf.
Actually, I think it's a horrid kluge that the alternate-location
mechanism depends on environment variables at all. (For one thing,
it's obviously not true that all the pathname-looking environment values
in a typical postgres user's environment are intended as alternate
database locations --- PWD being the most universal counterexample.
There is probably a security hole here.)
I have been thinking that perhaps we could rip out that mess when
we implement tablespaces. Creation of a tablespace could be the
(superuser-only) operation that replaces definition of an
alternate-location environment variable.
But your thought of a separate config file might be a good short-term
solution. Names and paths listed in such a file would be known to
be intended as alternate locations. Instead of looking at the
environment, we'd read the config file to see if an alternate location
is valid.
Anyone feel like working on this?
regards, tom lane
On Thursday 23 August 2001 14:36, Tom Lane wrote:
I have been thinking that perhaps we could rip out that mess when
we implement tablespaces. Creation of a tablespace could be the
(superuser-only) operation that replaces definition of an
alternate-location environment variable.
This is the real solution, Tom. Should developer time be spent on working
out an interim solution when what everybody _really_ wants is tablespaces?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
On Thursday 23 August 2001 14:36, Tom Lane wrote:
I have been thinking that perhaps we could rip out that mess when
we implement tablespaces. Creation of a tablespace could be the
(superuser-only) operation that replaces definition of an
alternate-location environment variable.This is the real solution, Tom. Should developer time be spent on working
out an interim solution when what everybody _really_ wants is tablespaces?
Of course, time is also a factor here... eg. being able to handle the
current options in config files for 7.2 still makes sense if
tablespaces won't make it until 7.3 or later.
--
Trond Eivind Glomsr�d
Red Hat, Inc.