Thread: pg_ctl of postgres 8.4 doesn't behave the same than 9.x when using a custom unix socket path

pg_ctl of postgres 8.4 doesn't behave the same than 9.x when using a custom unix socket path

From

Cécile Tonglet

Date:

07 May 2014, 13:20:13

In brief

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:

listen_addresses = ''
unix_socket_directory = '/run/postgresql-8.4'

Then I run:

. /etc/conf.d/postgresql-8.4

(to load the configuration variable of Gentoo in my current shell)

su -c "pg_ctl84 start -D ${DATA_DIR} -s -l ${DATA_DIR}/postmaster.log -o \"-p ${PGPORT} -D ${PGDATA} --data-directory=${DATA_DIR}\" -w -t 300" postgres

Here are the log in ${DATA_DIR}/postmaster.log:

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

Best regards

Re: pg_ctl of postgres 8.4 doesn't behave the same than 9.x when using a custom unix socket path

From

Tom Lane

Date:

07 May 2014, 13:49:32

Cécile Tonglet <cecile.tonglet@gmail.com> writes:
> 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*.

Sorry, you're out of luck on that.  Pre-9.1 postmasters don't report
their socket location in postmaster.pid, so pg_ctl doesn't have a way
to find it out if it's not default.
        regards, tom lane