Warn if initdb's --sync-only option is mixed with other options
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t44515psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 04:37 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t44515_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t44515_1 && git checkout t44515_1Patchset v1 (message #1) is on t44515_1
When reading through code for my previous patch [1]Slightly improve initdb --sync-only option's help message /messages/by-id/CABwTF4U6hbNNE1bv=LxQdJybmUdZ5NJQ9rKY9tN82NXM8QH+iQ@mail.gmail.com I realized that
initdb does *not* warn users that it ignores all other options (except
-D/--pgdata) if the --sync-only option is used.
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.
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.
[1]: Slightly improve initdb --sync-only option's help message /messages/by-id/CABwTF4U6hbNNE1bv=LxQdJybmUdZ5NJQ9rKY9tN82NXM8QH+iQ@mail.gmail.com
Slightly improve initdb --sync-only option's help message
/messages/by-id/CABwTF4U6hbNNE1bv=LxQdJybmUdZ5NJQ9rKY9tN82NXM8QH+iQ@mail.gmail.com
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
On 7 Jul 2021, at 04:23, Gurjeet Singh <gurjeet@singh.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/
On 7 Jul 2021, at 15:25, Daniel Gustafsson <daniel@yesql.se> wrote:
I doubt it's worth complicating the code for this fringe case though.
This thread has stalled, and with the updated docs/help output done for this
option I don't think this is worth pursuing (especially given the lack of
complaints over behavior which has existed for a very long time). I'm marking
this returned with feedback.
--
Daniel Gustafsson https://vmware.com/