Re: Tom Lane 2014-06-18 <21034.1403110...@sss.pgh.pa.us> > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers