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

Started by Cécile Tongletalmost 12 years ago2 messagesbugs
Jump to latest
#1Cécile Tonglet
cecile.tonglet@gmail.com

*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" po
stgres

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Cécile Tonglet (#1)
Re: pg_ctl of postgres 8.4 doesn't behave the same than 9.x when using a custom unix socket path

=?UTF-8?Q?C=C3=A9cile_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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs