Thread

1. what's going on? (was: Re: [HACKERS] createdb problem)

   Jeff Hoffmann <jeff@remapcorp.com> — 1998-11-24T14:49:15Z

   >I use postgres v6.4. My standard database is in /usr/local/pgsql/data
   >directory and the PGDATA environment variable points to this database
   >directory. But I'd like to create another database into another
   >directory. So I tried this:
   >killall postmaster
   >initdb --pgdata=/home/postgres/database    --that's OK
   >postmaster -i -D /home/postgres/database -S -o -F
   >createdb -D /home/postgres/database  gazmuvek   --that's not good
   >    the answer is:
   >ERROR: Unable to locate path '/home/postgres/database/gazmuvek'
   >                 This may be due to a missing environment variable in
   >the server
   >
   >After this I tried to type another command:
   >createdb gazmuvek
   >It was successfull, but the database 'gazmuvek' was created into
   >$PGDATA. But it wasn't my desire. I need the database 'gazmuvek' in the
   >directory: /home/postgres/database!
   >
   >
   >What is the solution?
   
   i'm a bit confused; it seems like you have a secondary storage area
   (/home/postgres/database) and a primary storage area
   (/usr/local/pgsql/data).  i think if you have a PGDATA environment variable,
   you'll be stuck running that instance of the postmaster with a primary
   storage location given in the evironment variable, even if you try to
   override it with an absolute path (at least from my limited testing - i
   tried exactly what you did with no success, even though logically it should
   result in "a clean slate" running from the secondary location).  and i
   haven't been able to create a database in a secondary location by specifying
   an absolute path, only with environment variables (as of 6.4, it worked OK
   in 6.3.2, though)
   
   so for you hackers out there: what's going on?  it seems that environment
   variables are the _one true way_ for 6.4, which is a change from 6.3.2.  if
   that's the case, most docs don't reflect it, and if not, then there very
   well could be some bugs somewhere.
   
   on to the solution, though.  what you probably want to do is kill the
   server, set a PGDATA2 environment variable to /home/postgres/database,
   restart the server (without the -D /home/postgres/database, just let it use
   the PGDATA location) and then set up the secondary storage area, e.g.:
   
   $ initlocation $PGDATA2
   $ createdb -D PGDATA2 gazmuvek
   
   this is really the correct way of doing things anyway, if you think through
   it a little bit.
   
   
   

2. Re: what's going on? (was: Re: [HACKERS] createdb problem)

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-11-25T02:13:08Z

   > ... and i haven't been able to create a database in a secondary 
   > location by specifying an absolute path, only with environment 
   > variables (as of 6.4, it worked OK in 6.3.2, though)
   > ... it seems that environment variables are the _one true way_ for 
   > 6.4, which is a change from 6.3.2.  if that's the case, most docs 
   > don't reflect it, and if not, then there very well could be some bugs 
   > somewhere.
   
   Yes, you are right that the default behavior has changed. Allowing
   absolute path names exposes the Postgres server to security and
   integrity risks (which may not be entirely alleviated by using
   environment variables, but imho it does help). The old behavior is
   recoverable by specifying
   
     #define ALLOW_ABSOLUTE_DBPATHS 1
   
   in your config.h or by specifying
   
     CFLAGS+= -DALLOW_ABSOLUTE_DBPATHS
   
   in your Makefile.custom.
   
   You are also correct in that the docs don't seem to explicitly discuss
   this issue though it is hinted at in the Admin Guide chapter on Disk
   Management (no mention of ALLOW_ABSOLUTE_DBPATHS though). Similar words
   appear in the User's Guide chapter on Database Management. I would have
   guessed that I had added something at the time, but...
   
   If you are annoyed enough by the lack of information to write some docs
   then the files to modify are manage.sgml (for the UG) and start-ag.sgml
   (for the AG). Patches gladly accepted :) I can give you back formatted
   versions so you can see how it looks.
   
   > ... this is really the correct way of doing things anyway, if you 
   > think through it a little bit.
   
   Your solution is correct.
   
   Regards.
   
                       - Tom