More legacy code: pg_ctl
Folks,
Speaking of legacy code with bad default behaviors: pg_ctl. The current
utility is designed to fathfully reproduce the rather hackish shell
script we originally had for postgres startup. This results in a
couple of unintuitive defaults which give sysadmins and config
management developers headaches:
a) by default, it returns to the caller without waiting for postgres to
actually start/stop/restart. In this mode, it also always returns
success regardless of result.
b) by default, it remains attached to the caller's tty for stdout and
stderr, even after it has switched to the regular postgres log.
Yes, one can work around both of these with -w and -l, but the only
reason those are non-default settings is that's the way the 7.X era
shell script behaved. So at this point we're preserving unintuitive
default behavior in order to be backwards compatible with a 1999-era
shell script.
I don't know if the answer is to rename the utility like we're
discussing with pg_dump/pg_backup, or something else.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/18/2013 05:09 PM, Josh Berkus wrote:
Folks,
Speaking of legacy code with bad default behaviors: pg_ctl. The current
utility is designed to fathfully reproduce the rather hackish shell
script we originally had for postgres startup. This results in a
couple of unintuitive defaults which give sysadmins and config
management developers headaches:a) by default, it returns to the caller without waiting for postgres to
actually start/stop/restart. In this mode, it also always returns
success regardless of result.b) by default, it remains attached to the caller's tty for stdout and
stderr, even after it has switched to the regular postgres log.
Oh, and one more:
c) that "stop" defaults to "smart" mode, instead of "fast" mode.
Yes, one can work around both of these with -w and -l, but the only
reason those are non-default settings is that's the way the 7.X era
shell script behaved. So at this point we're preserving unintuitive
default behavior in order to be backwards compatible with a 1999-era
shell script.I don't know if the answer is to rename the utility like we're
discussing with pg_dump/pg_backup, or something else.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM53e386198733a98bcf13ebc853262e572954967b921995b5345e3cdff9716b14247c77d41eefc5ac07a010039a84f35e@asav-1.01.com
On Mon, Nov 18, 2013 at 8:20 PM, Josh Berkus <josh@agliodbs.com> wrote:
On 11/18/2013 05:09 PM, Josh Berkus wrote:
Folks,
Speaking of legacy code with bad default behaviors: pg_ctl. The current
utility is designed to fathfully reproduce the rather hackish shell
script we originally had for postgres startup. This results in a
couple of unintuitive defaults which give sysadmins and config
management developers headaches:a) by default, it returns to the caller without waiting for postgres to
actually start/stop/restart. In this mode, it also always returns
success regardless of result.b) by default, it remains attached to the caller's tty for stdout and
stderr, even after it has switched to the regular postgres log.Oh, and one more:
c) that "stop" defaults to "smart" mode, instead of "fast" mode.
And that "smart" mode is called "smart" instead of "footgun".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/19/2013 08:29 AM, Robert Haas wrote:
On Mon, Nov 18, 2013 at 8:20 PM, Josh Berkus <josh@agliodbs.com> wrote:
Oh, and one more:
c) that "stop" defaults to "smart" mode, instead of "fast" mode.
And that "smart" mode is called "smart" instead of "footgun".
Right, exactly.
Personally, I can't think of a single time over the last 8 years when
I've actually wanted "smart" mode. Triggered it accidentally, hundreds
of times. Wanted it, no.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMa8360da840f9fedac0dc5454bb2365ef53436e9d1701e2cbbddb113a0f01004286e55c31a222e5d9b48177edd6f9bce1@asav-3.01.com
On 11/18/13, 8:09 PM, Josh Berkus wrote:
a) by default, it returns to the caller without waiting for postgres to
actually start/stop/restart. In this mode, it also always returns
success regardless of result.
The reason for this is that until sometime recently (PQping) we didn't
have a reliable way to check whether the server is up. This might be
different now, but it would need to be verified.
b) by default, it remains attached to the caller's tty for stdout and
stderr, even after it has switched to the regular postgres log.
Can pg_ctl tell when the postgres log has switched?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/18/13, 8:20 PM, Josh Berkus wrote:
c) that "stop" defaults to "smart" mode, instead of "fast" mode.
This has been discussed many times already, so you'd need to check the
archives. (I'm not in favor of smart mode either.)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers