Re: Trouble with amcheck

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Douglas Doole <dougdoole(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Trouble with amcheck
Date: 2017-09-15 02:43:36
Message-ID: 12454.1505443416@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Andres Freund (andres(at)anarazel(dot)de) wrote:
>> I'm very unconvinced by this, given that one use of installcheck is to
>> run against an existing server. For which one might not even have access
>> to the relevant directories to install extensions into.

> Sure, but if the extensions aren't in place and you're trying to run
> make installcheck-world, it's not like it's somehow going to succeed.

I'm more or less with Andres: this is just pilot error. If you didn't
do install-world you shouldn't expect installcheck-world to succeed.

> Now, that said, perhaps a bit more smarts would be in order here to,
> instead, check that the extensions are available before trying to run
> the checks for them. I'm thinking about something like this: check if
> the extension is available and, if not, skip the check of that module,
> with a warning or notification that it was skipped because it wasn't
> available.

Meh. I'm worried that that would have undesirable failure modes,
ie letting something pass when it should have failed.

Maybe we need some documentation improvements, though, to clarify
the relationships between these make targets.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-09-15 02:45:45 Re: parallelize queries containing initplans
Previous Message Andres Freund 2017-09-15 02:38:58 Re: Trouble with amcheck