FAQ
All,

pg_ctl -D means different things depending on whether you are calling
"start" or "stop". For "start", pg_ctl wants the directory
postgresql.conf is in, and for "stop" it wants the directory
postmaster.pid is in. This means that if your .conf files are not in
the same directory as data_directory, you have to write special-case
code for start and stop.

Given that having the .conf files in /etc is the default configuration
for both Red Hat and Debian, this seems like really poor UI design on
our part. Also, it makes the "data_directory" parameter somewhat
disingenous, because effectively that parameter doesn't work all the time.

It actually seems relatively easy to fix this without breaking
backwards-compatibility. We should add this logic to "pg_ctl stop":

1) if postmaster.pid is in -D, shut down that pid.
2) if postmaster.pid is not in -D, look for postgresql.conf
3) if postgresql.conf is found, look in data_directory for postmaster.pid

This would end the pg_ctl breakage on our most popular platforms, while
not changing any functionality for those already installed. Objections?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

Search Discussions

  • Tom Lane at Jun 1, 2011 at 9:10 pm

    Josh Berkus writes:
    pg_ctl -D means different things depending on whether you are calling
    "start" or "stop". For "start", pg_ctl wants the directory
    postgresql.conf is in, and for "stop" it wants the directory
    postmaster.pid is in. This means that if your .conf files are not in
    the same directory as data_directory, you have to write special-case
    code for start and stop.
    Well, the entire business of allowing the config files to be outside the
    data directory is bad design/poor UI. It's not pg_ctl that's the main
    problem here.
    Given that having the .conf files in /etc is the default configuration
    for both Red Hat and Debian, this seems like really poor UI design on
    our part.
    I can't speak for Debian, but the above statement is 100% false for Red
    Hat. In any case, no RH system has ever expected users to issue pg_ctl
    start/stop directly, and I think the same is true for Debian, so the
    bizarre design wouldn't matter to us even if the case did apply.
    It actually seems relatively easy to fix this without breaking
    backwards-compatibility.
    No, it isn't. You're making way too many assumptions about where things
    really were and what arguments were given to pg_ctl start. We went
    around on this before, which is why it's not "fixed" already.

    regards, tom lane
  • Jaime Casanova at Jun 1, 2011 at 9:28 pm

    On Wed, Jun 1, 2011 at 4:10 PM, Tom Lane wrote:
    I can't speak for Debian, but the above statement is 100% false for Red
    Hat.  In any case, no RH system has ever expected users to issue pg_ctl
    start/stop directly, and I think the same is true for Debian, so the
    bizarre design wouldn't matter to us even if the case did apply.
    that's right, the debian way is pg_ctlcluster

    --
    Jaime Casanova         www.2ndQuadrant.com
    Professional PostgreSQL: Soporte y capacitación de PostgreSQL
  • Robert Haas at Jun 1, 2011 at 10:23 pm

    On Wed, Jun 1, 2011 at 5:10 PM, Tom Lane wrote:
    Josh Berkus <josh@agliodbs.com> writes:
    pg_ctl -D means different things depending on whether you are calling
    "start" or "stop".  For "start", pg_ctl wants the directory
    postgresql.conf is in, and for "stop" it wants the directory
    postmaster.pid is in.  This means that if your .conf files are not in
    the same directory as data_directory, you have to write special-case
    code for start and stop.
    Well, the entire business of allowing the config files to be outside the
    data directory is bad design/poor UI.  It's not pg_ctl that's the main
    problem here.
    Given that having the .conf files in /etc is the default configuration
    for both Red Hat and Debian, this seems like really poor UI design on
    our part.
    I can't speak for Debian, but the above statement is 100% false for Red
    Hat.  In any case, no RH system has ever expected users to issue pg_ctl
    start/stop directly, and I think the same is true for Debian, so the
    bizarre design wouldn't matter to us even if the case did apply.
    It actually seems relatively easy to fix this without breaking
    backwards-compatibility.
    No, it isn't.  You're making way too many assumptions about where things
    really were and what arguments were given to pg_ctl start.  We went
    around on this before, which is why it's not "fixed" already.
    ISTM that it would be useful to run postgres in a mode where it
    doesn't actually try to start up the database, but parses
    postgresql.conf and then exits, perhaps printing out the value of a
    certain GUC as it does so. In this case, data_directory.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • Alvaro Herrera at Jun 1, 2011 at 10:57 pm

    Excerpts from Robert Haas's message of mié jun 01 18:22:56 -0400 2011:

    ISTM that it would be useful to run postgres in a mode where it
    doesn't actually try to start up the database, but parses
    postgresql.conf and then exits, perhaps printing out the value of a
    certain GUC as it does so. In this case, data_directory.
    I had the same thought, and wondered if we could use the feature
    elsewhere.

    --
    Álvaro Herrera <alvherre@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Tom Lane at Jun 1, 2011 at 11:07 pm

    Alvaro Herrera writes:
    Excerpts from Robert Haas's message of mié jun 01 18:22:56 -0400 2011:
    ISTM that it would be useful to run postgres in a mode where it
    doesn't actually try to start up the database, but parses
    postgresql.conf and then exits, perhaps printing out the value of a
    certain GUC as it does so. In this case, data_directory.
    I had the same thought, and wondered if we could use the feature
    elsewhere.
    This was suggested quite some time ago, IIRC, but we never got round to it.

    The main problem in the current context is that it only fixes the issue
    so long as you ignore the possibility that relevant values were
    specified on the command line or via environment variables, rather than
    coming directly from the config file. PGDATA is thus a particular
    hazard here: all you need is to be running with a different PGDATA
    setting in your environment than was used when "pg_ctl start" was
    issued, and you're hosed.

    regards, tom lane
  • Robert Haas at Jun 2, 2011 at 2:40 pm

    On Wed, Jun 1, 2011 at 7:07 PM, Tom Lane wrote:
    Alvaro Herrera <alvherre@commandprompt.com> writes:
    Excerpts from Robert Haas's message of mié jun 01 18:22:56 -0400 2011:
    ISTM that it would be useful to run postgres in a mode where it
    doesn't actually try to start up the database, but parses
    postgresql.conf and then exits, perhaps printing out the value of a
    certain GUC as it does so.  In this case, data_directory.
    I had the same thought, and wondered if we could use the feature
    elsewhere.
    This was suggested quite some time ago, IIRC, but we never got round to it.

    The main problem in the current context is that it only fixes the issue
    so long as you ignore the possibility that relevant values were
    specified on the command line or via environment variables, rather than
    coming directly from the config file.  PGDATA is thus a particular
    hazard here: all you need is to be running with a different PGDATA
    setting in your environment than was used when "pg_ctl start" was
    issued, and you're hosed.
    I guess I'm missing something here. If you change PGDATA, you're
    going to be working on a different cluster, but that's what you asked
    for. I guess there could be a problem if you used pg_ctl -D dir
    start, and postgres --tell-me-the-data-dir relied on PGDATA in telling
    you what the data directory should be, but that seems simple to work
    around: just have -D dir set $PGDATA before invoking postgres.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • Bruce Momjian at Jun 9, 2011 at 5:02 pm

    Robert Haas wrote:
    On Wed, Jun 1, 2011 at 7:07 PM, Tom Lane wrote:
    Alvaro Herrera <alvherre@commandprompt.com> writes:
    Excerpts from Robert Haas's message of mi? jun 01 18:22:56 -0400 2011:
    ISTM that it would be useful to run postgres in a mode where it
    doesn't actually try to start up the database, but parses
    postgresql.conf and then exits, perhaps printing out the value of a
    certain GUC as it does so. ?In this case, data_directory.
    I had the same thought, and wondered if we could use the feature
    elsewhere.
    This was suggested quite some time ago, IIRC, but we never got round to it.

    The main problem in the current context is that it only fixes the issue
    so long as you ignore the possibility that relevant values were
    specified on the command line or via environment variables, rather than
    coming directly from the config file. ?PGDATA is thus a particular
    hazard here: all you need is to be running with a different PGDATA
    setting in your environment than was used when "pg_ctl start" was
    issued, and you're hosed.
    I guess I'm missing something here. If you change PGDATA, you're
    going to be working on a different cluster, but that's what you asked
    for. I guess there could be a problem if you used pg_ctl -D dir
    start, and postgres --tell-me-the-data-dir relied on PGDATA in telling
    you what the data directory should be, but that seems simple to work
    around: just have -D dir set $PGDATA before invoking postgres.
    Is this just part of our existing TODOs?

    --
    Bruce Momjian <bruce@momjian.us> http://momjian.us
    EnterpriseDB http://enterprisedb.com

    + It's impossible for everything to be true. +
  • Josh Berkus at Jun 1, 2011 at 10:23 pm

    No, it isn't. You're making way too many assumptions about where things
    really were and what arguments were given to pg_ctl start. We went
    around on this before, which is why it's not "fixed" already.
    What should I search on? I can't find the relevant discussion.

    --
    Josh Berkus
    PostgreSQL Experts Inc.
    http://pgexperts.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 1, '11 at 7:56p
activeJun 9, '11 at 5:02p
posts9
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase