Re: Warn if initdb's --sync-only option is mixed with other options

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Gurjeet Singh <gurjeet(at)singh(dot)im>
Cc: Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Warn if initdb's --sync-only option is mixed with other options
Date: 2021-07-07 13:25:13
Message-ID: 0BE9E0AC-BA09-4510-B683-AB169D1174C4@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 7 Jul 2021, at 04:23, Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:

> I'm not able to come up with an exact situation to prove this, but
> this behaviour seems potentially dangerous. The user might mix the
> --sync-only option with other options, but would be extremely
> surprised if those other options didn't take effect.

Is if there is a plausible real world situation where a user runs --sync-only
together with other arguments and also miss the fact that the other arguments
didn't take effect, and have bad consequences?

> I _think_ we should throw an error if the user specifies any options
> that are being ignored. But an error might break someone's automation
> (perhaps for their own good), since the current behaviour has been in
> place for a very long time, so I'm willing to settle for at least a
> warning in such a case.

We typically don't issue warnings for incompatible arguments, but rather error
out, and I'm not convinced this warrants breaking that. If we are going to do
anything I think we should error out; if we decide to do something then we
consider the scripts that will break to already be broken.

A slightly confusing aspect of this is however the error message for sync-only
when -D or PGDATA isn't set says "will reside" when in fact it should say "is
residing" (or something along those lines):

$ ./bin/initdb --sync-only
initdb: error: no data directory specified
You must identify the directory where the data for this database system
will reside. Do this with either the invocation option -D or the
environment variable PGDATA.

I doubt it's worth complicating the code for this fringe case though.

--
Daniel Gustafsson https://vmware.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2021-07-07 13:32:08 Re: [PATCH] expand the units that pg_size_pretty supports on output
Previous Message Ranier Vilela 2021-07-07 13:24:18 Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)