Re: Is analyze_new_cluster.sh still useful?

From: Christoph Berg <christoph(dot)berg(at)credativ(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is analyze_new_cluster.sh still useful?
Date: 2014-06-20 12:26:05
Message-ID: 20140620122605.GC19839@msg.credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Re: Tom Lane 2014-06-18 <21034(dot)1403110303(at)sss(dot)pgh(dot)pa(dot)us>
> Christoph Berg <christoph(dot)berg(at)credativ(dot)de> writes:
> > now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't
> > it make sense to get rid of the analyze_new_cluster.sh file which
> > pg_upgrade writes? The net content is a single line which could as
> > well be printed by pg_upgrade itself. Instead of an lengthy
> > explanation how to invoke that manually, there should be a short note
> > and a pointer to some manual section. I think the chances of people
> > reading that would even be increased.
>
> > Similary, I don't really see the usefulness of delete_old_cluster.sh
> > as a file, when "rm -rf" could just be presented on the console for
> > the admin to execute by cut-and-paste.
>
> There are contexts where pg_upgrade is executed by some wrapper script
> and the user doesn't normally see its output directly. This is the
> case in the Red Hat packaging (unless Honza changed it since I left ;-))
> and I think Debian might be similar.

pg_upgradecluster shows the full pg_upgrade output in Debian. (But
pg_createcluster hides the initdb output, so it the other way round
here... It'd be nice if initdb would just output the interesting parts
and omit most of the chatter.)

> I generally don't like the amount of cruft pg_upgrade leaves lying
> around, so I'd be glad to see these script files go away if possible;
> but we need to think about how this will play when there's a wrapper
> script between pg_upgrade and the human user.
>
> In the Red Hat wrapper script, the pg_upgrade output is dumped into a
> log file, which the user can look at if he wants, but I'd bet the
> average user doesn't read it --- that was certainly the expectation.
> Of course, said user probably never notices the separate shell
> scripts either, so maybe it's a wash.
>
> Another angle is that some folks might have tried to automate things
> even more, with a wrapper script that starts up the new postmaster
> and runs analyze_new_cluster.sh all by itself. I guess they could
> make the wrapper do "vacuumdb --all --analyze-in-stages" directly,
> though, so maybe that's not a fatal objection either.

Yeah that was my point - that's a single static command, that could be
executed by the wrapper, and it would be much less opaque. (Same for
the delete script - before looking into the file you'd think it would
do all sorts of cleanup, but then issues a simple rm -rf.)

Mit freundlichen Grüßen,
Christoph Berg
--
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970 87C6 4C5A 6BAB 12D2 A7AE

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2014-06-20 13:32:33 Re: How to change the pgsql source code and build it??
Previous Message Fujii Masao 2014-06-20 12:25:07 Re: replication commands and log_statements