On 06/08/2017 03:04 AM, Neha Khatri wrote: > On 6/7/17, Tom Lane <t...@sss.pgh.pa.us> wrote: >> src/bin/pg_upgrade/TESTING claims (much further down in the file >> than I'd like): >> >> The shell script test.sh in this directory performs more or less this >> procedure. You can invoke it by running >> make check >> or by running >> make installcheck >> if "make install" (or "make install-world") were done beforehand. >> >> However, the second alternative doesn't really work: >> >> $ make installcheck >> make: Nothing to be done for `installcheck'. >> $ >> >> Did this ever work, or could it easily be made to work? > It seems it would work if the following two lines are uncommented from > the src/bin/pg_upgrade/Makefile: > > # disabled because it upsets the build farm > # installcheck: test.sh > # MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) $(SHELL) $< > > As the comment says, it was purposely disabled, probably to avoid > failure on cetain build farm members. > Attached the result of make installcheck after enabling the > intallcheck target (just to be sure if that is what you are looking > for). > >> If not, we need to fix that documentation. > If the attached is result is what you are after, should the > documentation be updated to mention that make installcheck is > purposely disabled, providing the reason for it. Or, should the > intallcheck target be enabled in the Makefile to find out if specific > buildfarm members still complain about it.
The whole thing is explained here: <https://www.postgresql.org/message-id/20327.1322435...@sss.pgh.pa.us> And since then the buildfarm has acquired a separate optional module that tests pg_upgrade. It's enabled by default in the sample config file. So it's not like we don't have buildfarm coverage - we do in fact. Re-enabling this in the Makefile would a) result in breakage on some members and b) make most members do redundant work. I vote for improving the docs. Let's also note that this test is not great anyway for a couple of reasons. First, it doesn't test as much as it might, only the core regression database. And second (and probably more importantly) it doesn't test cross-version upgrade, which, after all, is the reason for pg_upgrade's existence. There is an experimental buildfarm module that addresses both these issues, but it needs a bit of work to make it production ready. It runs (without reporting) on the animal crake, and has been stable since some time in April. I recently started work on bringing it up to production standard. It does take up a lot of space, since it's saving out binaries and databases that are normally removed at the end of each buildfarm run. On crake the static space required is 3.2Gb. That's in contrast to roughly 0.5 Gb used for all the supported branches for everything else. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers