Re: Prevent printing "next step instructions" in initdb and pg_upgrade

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Date: 2020-11-09 13:31:46
Message-ID: CABUevEy1Vf7aHOfUM+3fAW=is+sGGzL2BufPai6eRayEy=FkSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 9, 2020 at 2:18 PM Anastasia Lubennikova
<a(dot)lubennikova(at)postgrespro(dot)ru> wrote:
>
> 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.sql in src/bin/pg_upgrade/version.c with instructions.
> How should we handle them?

Oh, that's a good point. I had completely forgotten about those.

For consistency, one might say that those should be dropped as well.

But for usability that makes less sense. For the delete script, the
wrapper (that the switch is intended for) knows more than pg_upgrade
about how to delete it, so it can do a better job, and thus it makes
sense to silence it. But for something like these .sql (and also in
the previously mentioned case of extension upgrades), pg_upgrade knows
more and the only thing the wrapper could do is to reimplement the
same functionality, and maintain it.

I wonder if the best way forward might be to revert it back to being a
--no-instructions switch, remove the delete_old_cluster.sh script
completely and just replace it with instructions saying "you should
delete the old cluster", and then keep generating these scripts as
necessary?

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2020-11-09 13:41:01 Re: document pg_settings view doesn't display custom options
Previous Message Anastasia Lubennikova 2020-11-09 13:18:50 Re: Prevent printing "next step instructions" in initdb and pg_upgrade