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
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 reli
On 11/19/2013 08:29 AM, Robert Haas wrote:
> On Mon, Nov 18, 2013 at 8:20 PM, Josh Berkus 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 thin
On Mon, Nov 18, 2013 at 8:20 PM, Josh Berkus 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
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 defaul
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 developer
