Обсуждение: pg_ctl only allows 12 parameters?

On Monday, December 18, 2023, Ron Johnson <ronljohnsonjr@gmail.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.

Also, you are missing a line continuation backslash so you actually only supplied three arguments, where only 1 is accepted.

On Mon, Dec 18, 2023 at 10:11 AM David G. Johnston <david.g.johnston@gmail.com> wrote:

On Monday, December 18, 2023, Ron Johnson <ronljohnsonjr@gmail.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?

On Mon, Dec 18, 2023 at 8:31 AM Ron Johnson <ronljohnsonjr@gmail.com> wrote:

On Mon, Dec 18, 2023 at 10:11 AM David G. Johnston <david.g.johnston@gmail.com> wrote:

On Monday, December 18, 2023, Ron Johnson <ronljohnsonjr@gmail.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.

On Mon, Dec 18, 2023 at 10:41 AM David G. Johnston <david.g.johnston@gmail.com> wrote:

On Mon, Dec 18, 2023 at 8:31 AM Ron Johnson <ronljohnsonjr@gmail.com> wrote:

On Mon, Dec 18, 2023 at 10:11 AM David G. Johnston <david.g.johnston@gmail.com> wrote:

On Monday, December 18, 2023, Ron Johnson <ronljohnsonjr@gmail.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.

Ron Johnson <ronljohnsonjr@gmail.com> writes:
> On Mon, Dec 18, 2023 at 10:41 AM David G. Johnston <
> david.g.johnston@gmail.com> wrote:
>> 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.

The program's coding expects that optional switches will appear before
the action specifier.  You can get away with writing the action first
only if the version of getopt_long() that's in use will permute the
argument array to move non-options to the end.  That's always true on
glibc-based platforms, but otherwise usually not, at least in PG v14.

(Yes, I'm aware that pg_ctl's --help message claims this works
everywhere.  It's lying.)

Having said that, the most obvious way to explain the results you
seem to be getting is that you're using a version of getopt_long()
that tries to permute the arguments and is getting it wrong.
So, what's the platform?  And are you quite sure your psql is v14?

Ron Johnson <ronljohnsonjr@gmail.com> writes:
> On Mon, Dec 18, 2023 at 11:09 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So, what's the platform?  And are you quite sure your psql is v14?

> $ psql -V
> psql (PostgreSQL) 14.10
> $ postgres -V
> postgres (PostgreSQL) 14.10
> $ cat /etc/redhat-release
> Red Hat Enterprise Linux release 8.9 (Ootpa)
> # This is a "SLES Expanded Support platform 8.9"
> # The above "Red Hat Enterprise Linux Server" string is only used to
> # keep software compatibility.

Hmph.  I'm on (genuine) RHEL 8.9, and when I tried the command you
showed it seemed to work fine.  So there's some important detail
you've not provided.  Now I'm wondering about things like invisible
characters and whether you managed to type something that looks like
a "-" but is really some weird unicode character.

Looking at the v14 pg_ctl code, I see it has an extra level of
looping around getopt_long to try to cope with implementations
that don't permute the arguments.  So in theory it should work as
documented everywhere.  But I could see how things might get
confused, if the subroutine misidentifies what is a switch.