Prevent printing "next step instructions" in initdb and pg_upgrade

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Prevent printing "next step instructions" in initdb and pg_upgrade

Magnus Hagander-2
The attached patch adds a switch --no-instructions to initdb and pg_upgrade, which prevents them from printing instructions about how to start the cluster (initdb) or how to analyze and delete clusters (pg_upgrade).

The use case for this is for example the debian or redhat package wrappers. When these commands are run under those wrappers the printed instructions are *wrong*. It's better in that case to exclude them, and let the wrapper be responsible for printing the correct instructions.

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.

no-instructions.patch (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ian Lawrence Barwick
2020年10月6日(火) 19:26 Magnus Hagander <[hidden email]>:
>
> The attached patch adds a switch --no-instructions to initdb and pg_upgrade, which prevents them from printing instructions about how to start the cluster (initdb) or how to analyze and delete clusters (pg_upgrade).
>
> The use case for this is for example the debian or redhat package wrappers. When these commands are run under those wrappers the printed instructions are *wrong*. It's better in that case to exclude them, and let the wrapper be responsible for printing the correct instructions.
>
> 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.

As the switches are doing slightly different things (just omitting verbiage
versus omitting verbiage *and* not generating some script files) it
seems reasonable
not to try and shoehorn them into a using a unified but ambiguous name
name. Particularly as they're intended to be used in scripts themselves, so
it's not like it's important to create something that users can remember
easily for frequent use.

Alternatively, rather than describing what is not being done, the switch
could be called "--script-mode" or similar with a description along the
lines of "produces output suitable for execution by packaging scripts"
or something, and detail what's being omitted (or done differently)
in the documentation page.

Regards

Ian Barwick


--
EnterpriseDB: https://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2


On Tue, Oct 6, 2020 at 1:49 PM Ian Lawrence Barwick <[hidden email]> wrote:
2020年10月6日(火) 19:26 Magnus Hagander <[hidden email]>:
>
> The attached patch adds a switch --no-instructions to initdb and pg_upgrade, which prevents them from printing instructions about how to start the cluster (initdb) or how to analyze and delete clusters (pg_upgrade).
>
> The use case for this is for example the debian or redhat package wrappers. When these commands are run under those wrappers the printed instructions are *wrong*. It's better in that case to exclude them, and let the wrapper be responsible for printing the correct instructions.
>
> 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.

As the switches are doing slightly different things (just omitting verbiage
versus omitting verbiage *and* not generating some script files) it
seems reasonable
not to try and shoehorn them into a using a unified but ambiguous name
name. Particularly as they're intended to be used in scripts themselves, so
it's not like it's important to create something that users can remember
easily for frequent use.

True.



Alternatively, rather than describing what is not being done, the switch
could be called "--script-mode" or similar with a description along the
lines of "produces output suitable for execution by packaging scripts"
or something, and detail what's being omitted (or done differently)
in the documentation page.

Hmm, I'm less sure about that one. One could argue that this should then also affect other things, like password prompting, to fulfill it's name. 

--
Reply | Threaded
Open this post in threaded view
|

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

Tom Lane-2
In reply to this post by Magnus Hagander-2
Magnus Hagander <[hidden email]> writes:
> The use case for this is for example the debian or redhat package wrappers.
> When these commands are run under those wrappers the printed instructions
> are *wrong*. It's better in that case to exclude them, and let the wrapper
> be responsible for printing the correct instructions.

Hm, does it matter?  I think those wrappers send the output to /dev/null
anyway.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2


On Tue, Oct 6, 2020 at 4:31 PM Tom Lane <[hidden email]> wrote:
Magnus Hagander <[hidden email]> writes:
> The use case for this is for example the debian or redhat package wrappers.
> When these commands are run under those wrappers the printed instructions
> are *wrong*. It's better in that case to exclude them, and let the wrapper
> be responsible for printing the correct instructions.

Hm, does it matter?  I think those wrappers send the output to /dev/null
anyway.

The debian ones don't, because they consider it useful information to the user. I'd say that it is, especially in the case of pg_upgrade. (Less so about initdb, but still a bit -- especially when creating secondary clusters) 
The redhat ones I believe sent it to a logfile, not to /dev/null. Meaning it's not in your face, but it still contains incorrect instructions.

--
Reply | Threaded
Open this post in threaded view
|

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

Tom Lane-2
Magnus Hagander <[hidden email]> writes:
> On Tue, Oct 6, 2020 at 4:31 PM Tom Lane <[hidden email]> wrote:
>> Hm, does it matter?  I think those wrappers send the output to /dev/null
>> anyway.

> The debian ones don't, because they consider it useful information to the
> user. I'd say that it is, especially in the case of pg_upgrade. (Less so
> about initdb, but still a bit -- especially when creating secondary
> clusters)
> The redhat ones I believe sent it to a logfile, not to /dev/null. Meaning
> it's not in your face, but it still contains incorrect instructions.

OK.  FWIW, I'd vote for separate --no-instructions and --no-scripts
switches.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

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

Bruce Momjian
On Tue, Oct  6, 2020 at 11:06:13AM -0400, Tom Lane wrote:

> Magnus Hagander <[hidden email]> writes:
> > On Tue, Oct 6, 2020 at 4:31 PM Tom Lane <[hidden email]> wrote:
> >> Hm, does it matter?  I think those wrappers send the output to /dev/null
> >> anyway.
>
> > The debian ones don't, because they consider it useful information to the
> > user. I'd say that it is, especially in the case of pg_upgrade. (Less so
> > about initdb, but still a bit -- especially when creating secondary
> > clusters)
> > The redhat ones I believe sent it to a logfile, not to /dev/null. Meaning
> > it's not in your face, but it still contains incorrect instructions.
>
> OK.  FWIW, I'd vote for separate --no-instructions and --no-scripts
> switches.

Works for me.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

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

Michael Paquier-2
On Tue, Oct 06, 2020 at 11:22:11AM -0400, Bruce Momjian wrote:
> On Tue, Oct  6, 2020 at 11:06:13AM -0400, Tom Lane wrote:
>> OK.  FWIW, I'd vote for separate --no-instructions and --no-scripts
>> switches.
>
> Works for me.

+1.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Eisentraut-6
In reply to this post by Magnus Hagander-2
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?

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

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

Bruce Momjian
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.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2


On Tue, Oct 27, 2020 at 11:53 AM Bruce Momjian <[hidden email]> 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.

Yeah, that's the one I was thinking of, but I was looking for something more generic than explicitly saying --no-delete-script. 

--
Reply | Threaded
Open this post in threaded view
|

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

Peter Eisentraut-6
In reply to this post by Bruce Momjian
On 2020-10-27 11:53, Bruce Momjian 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.

Well, that one can trivially be replaced by a printed instruction, too.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

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

Bruce Momjian
On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:

> On 2020-10-27 11:53, Bruce Momjian 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.
>
> Well, that one can trivially be replaced by a printed instruction, too.

True. On my system is it simply:

        rm -rf '/u/pgsql.old/data'

The question is whether the user is going to record the vacuumdb and rm
instructions that display at the end of the pg_upgrade run, or do we
need to write it down for them in script files.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2
On Tue, Oct 27, 2020 at 12:40 PM Bruce Momjian <[hidden email]> wrote:

>
> On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:
> > On 2020-10-27 11:53, Bruce Momjian 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.
> >
> > Well, that one can trivially be replaced by a printed instruction, too.
>
> True. On my system is it simply:
>
>         rm -rf '/u/pgsql.old/data'
>
> The question is whether the user is going to record the vacuumdb and rm
> instructions that display at the end of the pg_upgrade run, or do we
> need to write it down for them in script files.

That assumes for example that you've had no extra tablespaces defined
in it. And it assumes your config files are actually in the same
directory etc.

Now, pg_upgrade *could* create a script that "actually works" for most
things, since it connects to the system and could then enumerate
things like tablespaces and config file locations, and generate a
script that actually uses that information.

But getting that to cover things like removing/disabling systemd
services or init jobs or whatever the platform uses can quickly get
pretty complex I think...

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.

Thinking further, there has been one other thing that we've talked
about before, which is to have pg_upgrade either run extension
upgrades, or generate a script that would run extension upgrades. If
we want to do that as form of a script, then we're bringing the
scripts back into play again... But maybe that's actually an argument
for *not* having pg_upgrade generate that script, but instead either
do the extension upgrades automatically, or have a separate tool that
one can run independent of pg_upgrade...

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


Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2
On Mon, Nov 2, 2020 at 2:23 PM Magnus Hagander <[hidden email]> wrote:

>
> On Tue, Oct 27, 2020 at 12:40 PM Bruce Momjian <[hidden email]> wrote:
> >
> > On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:
> > > On 2020-10-27 11:53, Bruce Momjian 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.
> > >
> > > Well, that one can trivially be replaced by a printed instruction, too.
> >
> > True. On my system is it simply:
> >
> >         rm -rf '/u/pgsql.old/data'
> >
> > The question is whether the user is going to record the vacuumdb and rm
> > instructions that display at the end of the pg_upgrade run, or do we
> > need to write it down for them in script files.
>
> That assumes for example that you've had no extra tablespaces defined
> in it. And it assumes your config files are actually in the same
> directory etc.
>
> Now, pg_upgrade *could* create a script that "actually works" for most
> things, since it connects to the system and could then enumerate
> things like tablespaces and config file locations, and generate a
> script that actually uses that information.
>
> But getting that to cover things like removing/disabling systemd
> services or init jobs or whatever the platform uses can quickly get
> pretty complex I think...
>
> 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.
>
> Thinking further, there has been one other thing that we've talked
> about before, which is to have pg_upgrade either run extension
> upgrades, or generate a script that would run extension upgrades. If
> we want to do that as form of a script, then we're bringing the
> scripts back into play again... But maybe that's actually an argument
> for *not* having pg_upgrade generate that script, but instead either
> do the extension upgrades automatically, or have a separate tool that
> one can run independent of pg_upgrade...
PFA a rebased version of this patch on top of what has happened since,
and changing the pg_upgrade parameter to be --no-scripts.

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

no-instructions-2.patch (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Anastasia Lubennikova
In reply to this post by Magnus Hagander-2
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?
-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2
On Mon, Nov 9, 2020 at 2:18 PM Anastasia Lubennikova
<[hidden email]> 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/


Reply | Threaded
Open this post in threaded view
|

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

Álvaro Herrera
On 2020-Nov-09, Magnus Hagander wrote:

> 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?

How about a switch like "--with-scripts=<list>" where the list can be
"all" to include everything (default), "none" to include nothing, or a
comma-separated list of things to include?  (Also "--with-scripts=help"
to query which things are supported)  So
"--with-scripts=reindex_hash,largeobject" omits the useless
delete_old_cluster script and keeps the ones you want.

Perhaps you could see it in the negative direction as more convenient,
so --suppress-scripts=delete_old_cluster


Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2
On Mon, Nov 9, 2020 at 3:29 PM Alvaro Herrera <[hidden email]> wrote:

>
> On 2020-Nov-09, Magnus Hagander wrote:
>
> > 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?
>
> How about a switch like "--with-scripts=<list>" where the list can be
> "all" to include everything (default), "none" to include nothing, or a
> comma-separated list of things to include?  (Also "--with-scripts=help"
> to query which things are supported)  So
> "--with-scripts=reindex_hash,largeobject" omits the useless
> delete_old_cluster script and keeps the ones you want.
>
> Perhaps you could see it in the negative direction as more convenient,
> so --suppress-scripts=delete_old_cluster

What would be the actual use-case in this though?

I can see the --suppress-scripts=delete_old_cluster, but that's
basically the only usecase I can see for this. And for use in any
wrapper, that wrapper would have to know ahead of time what the
options would be... And if that's the only usecase, than this ends up
basically boiling down to the same as my suggestion just with a more
complex switch? :)

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


Reply | Threaded
Open this post in threaded view
|

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

Álvaro Herrera
On 2020-Nov-09, Magnus Hagander wrote:

> On Mon, Nov 9, 2020 at 3:29 PM Alvaro Herrera <[hidden email]> wrote:
> >
> > How about a switch like "--with-scripts=<list>" where the list can be
> > "all" to include everything (default), "none" to include nothing, or a
> > comma-separated list of things to include?  (Also "--with-scripts=help"
> > to query which things are supported)  So
> > "--with-scripts=reindex_hash,largeobject" omits the useless
> > delete_old_cluster script and keeps the ones you want.
> >
> > Perhaps you could see it in the negative direction as more convenient,
> > so --suppress-scripts=delete_old_cluster
>
> What would be the actual use-case in this though?

The point is that we can do this just this time, and then in the future
we'll already have a mechanism for emitting or suppressing scripts that
are useful for some cases but not others.  If I read you right, we
currenly have two cases: the user is either running it manually (in
which case you claim they want all scripts) or there's a wrapper (in
which case reindex_hash et al are useful, others are not).  But what if,
say, we determined that it's a good idea to suggest to migrate BRIN
indexes from v1 to v2 for datatype X?  If your tooling is prepared to
deal with that then it'll find the script useful, otherwise it's junk.
And we don't have to have a new option "--include-brin-upgrade" or
whatever; just add a new value to the suppressable script list.



12