Re: pg_ctl only allows 12 parameters?

On Mon, Dec 18, 2023 at 8:48 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:

> On Mon, Dec 18, 2023 at 10:41 AM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Mon, Dec 18, 2023 at 8:31 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
>> wrote:
>>
>>> On Mon, Dec 18, 2023 at 10:11 AM David G. Johnston <
>>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>>
>>>> On Monday, December 18, 2023, Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
>>>> wrote:
>>>>
>>>>> PG 14.10
>>>>>
>>>>> pg_ctl failed when I added a thirteenth parameter (log_temp_files).
>>>>> Is this documented, and I missed it?
>>>>>
>>>>> (The purpose is to optimize for a 30-thread pg_restore of a multi-TB
>>>>> 9.6 database. Once it's finished, I stop/start, to enable "production"
>>>>> values like fsync=on.)
>>>>>
>>>>> pg_ctl restart -wt999 -mfast
>>>>> -o '-c fsync=off' \
>>>>> -o '-c full_page_writes=off' \
>>>>> -o '-c log_statement=none' \
>>>>> -o '-c log_temp_files=100kB' \
>>>>> -o '-c max_wal_size=36GB' \
>>>>> -o '-c wal_level=minimal' \
>>>>> -o '-c max_wal_senders=0' \
>>>>> -o '-c wal_buffers=64MB' \
>>>>> -o '-c log_checkpoints=off' \
>>>>> -o '-c autovacuum=off'
>>>>> pg_ctl: too many command-line arguments (first is "restart")
>>>>>
>>>>
>>>> Arguments are not parameters. Try putting the restart argument after
>>>> all parameters.
>>>>
>>>
>>> Quite irritating. "pg_ctl restart" instantly tells you what it's doing.
>>>
>>> And still, why the limitation?
>>>
>>
>> I'm thinking that the forced ordering being different than what is
>> documented is a shell-specific issue. As for why only one of restart,
>> stop, start, etc... can be specified for any given invocation of pg_ctl,
>> that seems like an entirely realistic limitation and typo-preventing
>> feature.
>>
>
> The error message is "pg_ctl: *too many command-line arguments*". It's
> manifestly obvious that the command failed when I added a "-" option, not a
> "start", "stop" command. and yet pg_ctl complained about command-line
> arguments.
>

As soon as you supplied "restart" the CLI parser code for your
shell/whatnot stopped looking for options/parameters and everything else
subsequent is defined to be an argument. As soon as it sees a second
argument for a command that is defined to only have a single argument the
parser immediately aborts.

Yes, I'm describing what is observed. I don't know precisely which
tooling is "at fault" here or who could make it behave differently but
the concept of options first, everything after the last option/first
argument is an argument is something that exists and is what you are seeing
here.

David J.