Horton

Thread

Commits

  1. Fix bit-rot in pg_upgrade's test.sh, and improve documentation.

  1. Does pg_upgrade really support "make installcheck"?

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-06-08T03:28:02Z

    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?
If not, we need to fix that documentation.

			regards, tom lane

  2. Re: Does pg_upgrade really support "make installcheck"?

    Neha Khatri <nehakhatri5@gmail.com> — 2017-06-08T07:04:09Z

    On 6/7/17, Tom Lane <tgl@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.

-- 
Regards,
Neha

  3. Re: Does pg_upgrade really support "make installcheck"?

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2017-06-08T14:49:14Z

    
On 06/08/2017 03:04 AM, Neha Khatri wrote:
> On 6/7/17, Tom Lane <tgl@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.1322435869@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

  4. Re: Does pg_upgrade really support "make installcheck"?

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-06-08T15:02:16Z

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> The whole thing is explained here:
> <https://www.postgresql.org/message-id/20327.1322435869@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.

WFM, I'll go do that (and maybe improve the comment in the makefile)

			regards, tom lane