Thread: Bad UI design: pg_ctl and data_directory
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
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.
regards, tom lane
On Wed, Jun 1, 2011 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
On Wed, Jun 1, 2011 at 5:10 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
> 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
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
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.
regards, tom lane
On Wed, Jun 1, 2011 at 7:07 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
Robert Haas wrote: > On Wed, Jun 1, 2011 at 7:07 PM, Tom Lane <tgl@sss.pgh.pa.us> 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. +