Christoph Berg <christoph.b...@credativ.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. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers