Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
To: Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-11-09T13:18:50Z
Lists: pgsql-hackers
On 02.11.2020 16:23, Magnus Hagander wrote: >>>> On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote: >>>>> On 2020-10-06 12:26, Magnus Hagander wrote: >>>>>> I went with the name --no-instructions to have the same name for both >>>>>> initdb and pg_upgrade. The downside is that "no-instructions" also >>>>>> causes the scripts not to be written in pg_upgrade, which arguably is a >>>>>> different thing. We could go with "--no-instructions" and >>>>>> "--no-scripts", but that would leave the parameters different. I also >>>>>> considered "--no-next-step", but that one didn't quite have the right >>>>>> ring to me. I'm happy for other suggestions on the parameter names. >>>>> What scripts are left after we remove the analyze script, as discussed in a >>>>> different thread? >>>> There is still delete_old_cluster.sh. >>>> I wonder if we should just not do it and just say "you should delete >>>> the old cluster". Then we can leave it up to platform integrations to >>>> enhance that, based on their platform knowledge (such as for example >>>> knowing if the platform runs systemd or not). That would leave us with >>>> both pg_upgrade and initdb printing instructions, and not scripts, and >>>> solve that part of the issue. >>>> Do we only care about .sh scripts? There are also reindex_hash.sql and pg_largeobject.sqlin src/bin/pg_upgrade/version.c with instructions. How should we handle them? -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Commits
-
Remove extra Success message at the end of initdb
- e7f429148549 14.0 landed