Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of lun oct 03 17:06:16 -0300 2011:
> >
> > Magnus Hagander wrote:
> > > Well, how does the server get from the config file to where the state
> > > file is? Can we do it the same way, or even expose it to the tools
> > > using a commandline parameter or something?
> >
> > In that case (the Gentoo example), they use --data-directory
> >
> > su -l postgres \
> > -c "env PGPORT=\"${PGPORT}\" ${PG_EXTRA_ENV} \
> > /usr/lib/postgresql-9.0/bin/pg_ctl \
> > start ${WAIT_FOR_START} -t ${START_TIMEOUT} -s -D ${DATA_DIR} \
> > -o '-D ${PGDATA} --data-directory=${DATA_DIR} \
> > --silent-mode=true ${PGOPTS}'"
> >
> > We could have pg_ctl read that information from the command line for
> > pg_ctl start, but for pg_ctl stop, we have no way of getting to that
> > value. :-( It is not like something is missing from the code. The
> > user can start multiple clusters from a single config dir and the
> > information they give gives us no way to know which cluster they want,
> > or where is it located.
>
> Well, we have the Gentoo developer in this very thread. I'm sure they
> would fix their command line if we gave them a pg_ctl that worked.
> Surely the package that contains the init script also contains pg_ctl,
> so they would both be upgraded simultaneously.
What is the fix? If they started the server by using --data-directory,
pg_ctl stop has no way to find the postmaster.pid file, and hence stop
the server. Are you suggesting we remove this ability? We could
require the --data-directory to be specified for pg_ctl stop. Of
course, just specifying the real data directory for pg_ctl stop works
just fine so what is their motivation to specify both the configuration
and real data directories?
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
