example : ----------- bash-2.05b# /etc/init.d/postgresql start * directory not found: /var/lib/postgresql/data * You should create PGDATA directory first. but look at what PGDATA is. ---------------------------- bash-2.05b# echo $PGDATA /usr/share/postgresql/data bash-2.05b# In /etc/env.d/99local ---------------------- PGDATA=/usr/share/postgresql/data The command initdb has been used to create the cluster on /usr/share/postgresql/data and everything was initialized ok. It seems to me that the environment variables change when I run the script Here is a look at the script, the procedure checkconfig() seems to return the error msg. opts="${opts} reload" depend() { use net } checkconfig() { if [ ! -d $PGDATA ]; then eerror "directory not found: $PGDATA" eerror "You should create PGDATA directory first." return 1 fi } start() { checkconfig || return 1 Reproducible: Always Steps to Reproduce: 1. Create the file /etc/env.d/99local and insert a line PGDATA=<your choice of directory> #This directory must exist and owner should be postgres 2. Commit the changes by using the command env-update && source /etc/profile 3. Check that changes have been made by doing an echo $PGDATA 4. Change to the postgres user: su postgres 5. Check PGDATA again: echo $PGDATA 6. Give the command to make the cluster: initdb 7. Check that everything is initialized ok at <your choice of directory> 8. exit to root 9. /etc/init.d/posgresql start Actual Results: * directory not found: /var/lib/postgresql/data * You should create PGDATA directory first. Expected Results: Started postgresql using <your choice of directory> as the servers cluster. ebegin "Starting PostgreSQL" if [ -f $PGDATA/postmaster.pid ]; then rm $PGDATA/postmaster.pid fi su - $PGUSER -c "/usr/bin/pg_ctl start -D '$PGDATA' -s -l '$PGLOG' -o '$PGOPTS'"
Hi, /etc/conf.d/postgresql might overwrite PGDATA variable. Can you show me 'grep PGDATA /etc/conf.d/postgresql'?
Hi, Here is the result: bash-2.05b# grep PGDATA /etc/conf.d/postgresql PGDATA=/var/lib/postgresql/data
Hi, I have been poking around and found out the following. If you upgrade from an earlier version you may also get into trouble because of the postgres user that exists on the system, in other words the root of the problem is that an upgrade does not handle the situation as well as it could. If you install the package on a pc that has not got any previous ver. installed everything seems to work perfectly, except for all the places where /var/lib/postgress/data is hardcoded. Possible remedy, (just a suggestion) Instead of hardcoding /var/lib/postgre.... in several conf. files why not use $PGDATA instead in these files and put the value PGDATA=/var/lib/post... in say /etc/env.d/99local or some other file (which I don't know about). Then at first time install it would create this PGDATA line and when an updated ver. wanted to install it would check for this line and if it existed just use it. That way if a user has modified the location for PGDATA an upgrade would use the same location as the user wants.
hmartin, if you comment the line in etc/conf.d/postgresql out as workaround, it would work. And I'll modify /etc/conf.d/postgresql not to overwrite the value in the next ebuild version.
Why not have Postgresql create $PGDATA and set the correct permissions when Postgresql is installed for the first time?
Well, if you have to change the default path, do it in /etc/conf.d/postgresql. We won't introduce a global env var (which would interfere with the upcoming slotting of postgresql)
