I think there is an issue with pg_ctl of PostgreSQL 8.4, it doesn't behave the same than 9.1 and 9.3 (didn't tested 9.2 yet). It does not give me back the control if I use a unix socket different than /run/postgresql and disable listening.
Details
I'm running a Gentoo and try make multiple version of PostgreSQL running on the same system.
Instead of changing port, I prefer to disable the listening on an interface and use only a unix socket with a meaningful directory.
Here are the changes I made in the postgresql.conf file:
LOG: database system was shut down at 2014-05-07 02:56:22 CEST LOG: database system is ready to accept connections LOG: autovacuum launcher started LOG: received smart shutdown request LOG: autovacuum launcher shutting down LOG: shutting down LOG: database system is shut down LOG: database system was shut down at 2014-05-07 03:01:31 CEST LOG: autovacuum launcher started
The problem is The program never gives back the control to the parent process but the server is actually running normally. This is not the same behavior in 9.1 and 9.3. I get the control back in less than a second after I run the pg_ctl process.
It makes my system.d service stuck in "activating" state.
Here is system.d the status of the service:
postgresql-8.4.service - PostgreSQL database server Loaded: loaded (/usr/lib64/systemd/system/postgresql-8.4.service; enabled) Active: activating (start) since Wed 2014-05-07 03:30:25 CEST; 45s ago Process: 1041 ExecStartPre=/usr/bin/postgresql-8.4-check-db-dir (code=exited, status=0/SUCCESS) Main PID: 5437 (code=exited, status=1/FAILURE); : 1044 (pg_ctl) CGroup: /system.slice/postgresql-8.4.service ├─1044 /usr/lib/postgresql-8.4/bin/pg_ctl start -D /var/lib/postgresql/8.4/data -s -l /var/lib/postgresql/8.4/data/postmaster.log -o -p 5432 -D /e... ├─1047 /usr/lib64/postgresql-8.4/bin/postgres -D /var/lib/postgresql/8.4/data -p 5432 -D /etc/postgresql-8.4 --data-directory=/var/lib/postgresql/... ├─1049 postgres: writer process ├─1050 postgres: wal writer process ├─1051 postgres: autovacuum launcher process └─1052 postgres: stats collector process
This problem does not occur if I use the default unix socket path /run/postgresql