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

On Fri, Nov 20, 2020 at 4:46 PM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> On 2020-11-09 13:05, Magnus Hagander wrote:
> > PFA a rebased version of this patch on top of what has happened since,
> > and changing the pg_upgrade parameter to be --no-scripts.
>
> It seems were are still finding out more nuances about pg_upgrade, but
> looking at initdb for moment, I think the solution for wrapper scripts
> is to just run initdb with >dev/null. Or maybe if that looks a bit too
> hackish, a --quiet option that turns everything on stdout off.
>
> I think initdb has gotten a bit too chatty over time. I think if it
> printed nothing on stdout by default and the current output would be
> some kind of verbose or debug mode, we wouldn't really lose much. With
> that in mind, I'm a bit concerned about adding options (and thus
> documentation surface area etc.) to select exactly which slice of the
> chattiness to omit.

I agree that it's getting unnecessarily chatty, but things like the
locale that it has detected I think is very useful information to
output. Though I guess the same could be said for a few other things,
but does it *ever' pick anything other than 128Mb/100 for example? :)

The main difference between them is that some information is
informational but unnecessary, but the "next steps instructions" are
*incorrect* in most cases when executed by a wrapper. I'd argue that
even if we show them only with --verbose, we should still have a way
of not outputing the information that's going to be incorrect for the
end user.

I think it boils down to that today the output from initdb is entirely
geared towards people running initdb directly and starting their
server manually, and very few people outside the actual PostgreSQL
developers ever do that. But there are still a lot of people who run
initdb through their wrapper manually (for redhat you have to do that,
for debian you only have to do it if you're creating a secondary
cluster but that still a pretty common operation).

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