Summary: | The init script that starts posgresql does not care about changes in PGDATA | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Helge Thorbjørnsen <hmartin> |
Component: | Current packages | Assignee: | PgSQL Bugs <pgsql-bugs> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Helge Thorbjørnsen
2005-04-04 09:52:20 UTC
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) |