Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 488246 - =dev-db/postgresql-server-9.3.1 - pg_upgrade tool broken by config relocation
Summary: =dev-db/postgresql-server-9.3.1 - pg_upgrade tool broken by config relocation
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: PgSQL Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-16 15:37 UTC by John L. Poole
Modified: 2014-12-28 18:10 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John L. Poole 2013-10-16 15:37:34 UTC
Gentoo's installation of PostgreSQL 9.3 places the requisite configuration files under a directory other than where the standard PostgreSQL installation expects them.



Reproducible: Always

Steps to Reproduce:
1.  emerge dev-db/postgresql-server  [9.3]
2.  emerge --config =dev-db/postgresql-server-9.3.1
3.  /usr/lib/postgresql-9.3/bin/postgres -D /var/lib/postgresql/9.3/data
Actual Results:  
postgres cannot access the server configuration file "/var/lib/postgresql/9.3/data/postgresql.conf": No such file or directory


Expected Results:  
 /usr/lib/postgresql-9.3/bin/postgres -D /var/lib/postgresql/9.3/data
LOG:  database system was shut down at 2013-10-16 07:44:24 PDT
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started


The way I fixed the matter was to create softlinks:

postgres@atom ~/9.3/data $ ln -s /etc/postgresql-9.3/pg_hba.conf pg_hba.conf
postgres@atom ~/9.3/data $ ln -s /etc/postgresql-9.3/pg_ident.conf pg_ident.conf
postgres@atom ~/9.3/data $ ln -s /etc/postgresql-9.3/postgresql.conf postgresql.conf

This issue apparently was raised in 9.2, see Bug #461736.
Comment 1 Aaron W. Swenson gentoo-dev 2013-10-16 17:36:26 UTC
Use the initscript or systemd as recommended by the ebuild. If you choose not to do it the way outlined, you may be creative with your own stuff.

Bug 461736 is unrelated.
Comment 2 John L. Poole 2013-10-16 18:00:13 UTC
Here is what was printed to my console at the end of the emerge:

* Gentoo specific documentation:
 * http://www.gentoo.org/doc/en/postgres-howto.xml
 *
 * Official documentation:
 * http://www.postgresql.org/docs/9.3/static/index.html
 *
 * The default location of the Unix-domain socket is:
 *     /run/postgresql/
 *
 * Before initializing the database, you may want to edit PG_INITDB_OPTS
 * so that it contains your preferred locale in:
 *     /etc/conf.d/postgresql-9.3
 *
 * Then, execute the following command to setup the initial database
 * environment:
 *     emerge --config =dev-db/postgresql-server-9.3.1

 * Messages for package dev-db/postgresql-base-9.3.1:

 * If you need a global psqlrc-file, you can place it in:
 *     /etc/postgresql-9.3/

 * Messages for package dev-db/postgresql-server-9.3.1:

 * Gentoo specific documentation:
 * http://www.gentoo.org/doc/en/postgres-howto.xml
 *
 * Official documentation:
 * http://www.postgresql.org/docs/9.3/static/index.html
 *
 * The default location of the Unix-domain socket is:
 *     /run/postgresql/
 *
 * Before initializing the database, you may want to edit PG_INITDB_OPTS
 * so that it contains your preferred locale in:
 *     /etc/conf.d/postgresql-9.3
 *
 * Then, execute the following command to setup the initial database
 * environment:
 *     emerge --config =dev-db/postgresql-server-9.3.1
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

!!! existing preserved libs:
>>> package: dev-libs/boost-1.53.0
 *  - /usr/lib/libboost_filesystem.so.1.52.0
 *      used by /usr/bin/bsondump (dev-db/mongodb-2.4.3)
 *      used by /usr/bin/mongo (dev-db/mongodb-2.4.3)
 *      used by /usr/bin/mongod (dev-db/mongodb-2.4.3)
 *      used by 11 other files
 *  - /usr/lib/libboost_system.so.1.52.0
 *      used by /usr/bin/bsondump (dev-db/mongodb-2.4.3)
 *      used by /usr/bin/mongo (dev-db/mongodb-2.4.3)
 *      used by /usr/bin/mongod (dev-db/mongodb-2.4.3)
 *      used by 11 other files
 *  - /usr/lib/libboost_program_options.so.1.52.0
 *      used by /usr/bin/bsondump (dev-db/mongodb-2.4.3)
 *      used by /usr/bin/mongo (dev-db/mongodb-2.4.3)
 *      used by /usr/bin/mongod (dev-db/mongodb-2.4.3)
 *      used by 11 other files
 *  - /usr/lib/libboost_thread.so.1.52.0
 *      used by /usr/bin/bsondump (dev-db/mongodb-2.4.3)
 *      used by /usr/bin/mongo (dev-db/mongodb-2.4.3)
 *      used by /usr/bin/mongod (dev-db/mongodb-2.4.3)
 *      used by 11 other files
Use emerge @preserved-rebuild to rebuild packages using these libraries

I duly ran the recommended command:
    emerge --config =dev-db/postgresql-server-9.3.1

So I am not able to discern what you are referring to by "Use the initscript or systemd as recommended by the ebuild."  Where does the recommendation appear?
Comment 3 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-10-16 18:37:56 UTC
Just like with other servers, use the init script from /etc/init.d/ or the service from /usr/lib/systemd/system/ depending on which service manager you run.
Comment 4 John L. Poole 2013-10-16 18:55:23 UTC
I do use the /etc/init.d/postgres-X.X procedure... all the time for the last decade.

Yet, when I was using postgres's tools to migrate my 9.1 databases to 9.2, e.g. such as pg_upgrade, the problem manifested itself.

If the toolset shipped with postgres is not going to work against the instance created by the ebuild, then I submit there should be a message displayed at the completion of the ebuild warning so, or the ebuild should create an instance that does not break, e.g. creating softlinks, such as I have suggested.   

I still failing to understand Comment #1.  

Comment #2 doesn't seem to grasp what is at issue: simply using /etc/init.d doesn't solve the problem I ran into, to wit, using the postgres migration tools.

Let's take the scenario: user has a 9.1 database and installs 9.3 using an ebuild.  Then how is the user suppose to migrate the data using postgres' tools when the instance created is altered, e.g. the configuration files are moved elsewhere?  Shouldn't the ebuild either warn the user or fix the problem?
Comment 5 Aaron W. Swenson gentoo-dev 2013-10-16 18:58:18 UTC
After the emerge --config dev-db/postgresql-server:${SLOT} is finished, it states: You should use the '/etc/init.d/postgresql-${SLOT}' script to run PostgreSQL instead of 'pg_ctl'.

Additionally, the Gentoo-specific documentation indicates to use /etc/init.d/postgresql-${SLOT}. [1] It also states where the configuration files are located.

The systemd service file is a recent addition so it is not yet mentioned in the documentation, but it will be mentioned in the same locations.

Both 'pg_ctl' and 'postgresql' binaries take an option to define where to look for the configuration file and where the data directory is located. You can use those options, or you can make symlinks if you want.

[1] http://www.gentoo.org/doc/en/postgres-howto.xml
Comment 6 John L. Poole 2013-10-16 19:11:36 UTC
So the resolution of this bug is:

If you want to use the tools shipped with PostgreSQL 9.3 that will be rendered inoperative due to Gentoo's change of Postgres' standard configuration, go read Gentoo's documentation to fix it.

That's not the kind of experience I've found in other Gentoo ebuilds, the ebuilds take care of the problem, warn the user, or refer the user to further documentation.  This Bug shall serve as the 3rd alternative.

Were that the ebuild stated at the conclusion: "Due to Gentoo's configuration changes, some tools shipped with Postgres may not work; please refer to the Gentoo Documentation below for particulars."

(I haven't recently reviewed Gentoo's Postgres documentation and suppose it does alert readers on how to deal with the configuration file movement so the tools can be utilized.)
Comment 7 John L. Poole 2013-10-18 06:02:00 UTC
What really is at issue in this bug is that the ebuilds placement of specific postgreSQL configuration files ( pg_hba.conf  pg_ident.conf  postgresql.conf) under the /etc/postgresq-[version] directory in the Gentoo tradition has broken at last one postgreSQL tool, to wit: /usr/lib/postgresql-9.3/bin/pg_upgrade.   "pg_upgrade" is shipped in the package by PostgreSQL and can reasonably be expected to be used by anyone experienced in maintaining postgreSQL databases and duly upgrading same. 

By placing the three configuration files in another directory, the postgres tool, pg_upgrade, cannot stop and start the database because it expects the configuration files to be where PostgreSQL ships them.  The Gentoo practice of moving the configuration files under /etc should either fix the problem the realignment creates and/or allow for warnings to be displayed by the ebuild to alert users that the installation is less than perfect as the tools that ship with postgreSQL will not work without further alterations of additional parameters to the tools.


I postulated a scenario in my Comment #4 which describe what a reasonable man might encounter when upgrading postgres from 9.1 to 9.3 and I asked for a solution.  Instead of providing solution, this bug was summarily "closed" without addressing the very real issue of what is one suppose to do when they are not told the pg_upgrade tool will not work in the Gentoo installation.  

The new title just changed by Tom Wijsman hours ago skirts the very serious problem: the ebuilds relocation of postgreSQL's configuration scripts has broken a postgres tool(s).  I have no problem with relocation of the configuration files, I support that philosophy. I do have a problem with ebuilds which fail to inform or address problems it creates and it is discouraging to see resistance, if not condemnation, by the two commentators thus far to solutions that might help others.
Comment 8 Aaron W. Swenson gentoo-dev 2014-12-04 11:39:19 UTC
I have this addressed in my overlay. The ebuild will create symbolic links to the config files when PGDATA and DATADIR differ.