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

From Cécile Tonglet
Subject pg_ctl of postgres 8.4 doesn't behave the same than 9.x when using a custom unix socket path
Date
Msg-id CAGzYFG41u5dDqtoUp9yMAdU7kfVGdh_wSSpArcT_hVnoNNuhrg@mail.gmail.com
Whole thread Raw
Responses Re: pg_ctl of postgres 8.4 doesn't behave the same than 9.x when using a custom unix socket path  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #9635: Wal sender process is using 100% CPU
Next
From: Jamie Koceniak
Date:
Subject: Re: BUG #9635: Wal sender process is using 100% CPU