Re: make installcheck-world in a clean environment - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: make installcheck-world in a clean environment
Date
Msg-id 171724bb-0436-3665-6738-cbd42bdf9783@gmail.com
Whole thread Raw
In response to Re: make installcheck-world in a clean environment  (Michael Paquier <michael@paquier.xyz>)
Responses Re: make installcheck-world in a clean environment
List pgsql-hackers
Hello Michael,

12.09.2018 10:20, Michael Paquier wrote:
> On Mon, May 07, 2018 at 01:07:15PM -0400, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> After thinking about this some more, I think the question here is
>>> definitional.  A first attempt at defining 'make installcheck' is to
>>> say that it runs the tests from the build tree against the running
>>> server.  Certainly, we intend to use the SQL files that are present in
>>> the build tree, not the ones that were present in the build tree where
>>> the running server was built.  But what about client programs that we
>>> use to connect to the server?  You're suggesting that we use the
>>> pre-installed ones, but that is actually pretty problematic because
>>> the ones we see as installed might correspond neither to the contents
>>> of the build tree nor to the running server.  Conceivably we could end
>>> up having a mix of assets from three different places: (1) the running
>>> server, (2) the build tree, (3) whatever is in our path at the moment.
>>> That seems very confusing.  So now I think it's probably right to
>>> define 'make installcheck' as using the assets from the build tree to
>>> test the running server.  Under that definition, we're missing some
>>> dependencies, but USE_INSTALLED_ASSETS isn't a thing we need.
>> Nah, I disagree with this.  To me, the purpose of "make installcheck"
>> is to verify the correctness of an installation, which I take to include
>> the client programs as well as the server.  I think that "make
>> installcheck" ought to use the installed version of any file that we
>> actually install, and go to the build tree only for things we don't
>> install (e.g. SQL test scripts).
>>
>> If the user has screwed up his PATH or other environmental aspects so that
>> what he's testing isn't a single installation, that's his error, not
>> something that "make installcheck" ought to work around.  Indeed, maybe
>> such aspects of his setup are intentional, and second-guessing them would
>> completely defeat his purpose.  In any case, if you want to test the
>> build-tree assets, that's what "make check" is for.
> I agree with Tom's position, and this is the behavior that Postgres is
> using for ages for check and installcheck.  If there are no objections,
> I'll mark the patch as rejected and move on to other things.
> --
> Michael

It seems, that you miss a major part of the discussion (we have
discussed the issue from other positions later).
And I don't think that age of the behavior should prevail over it's
reasonability.

Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: Collation versioning
Next
From: Ioseph Kim
Date:
Subject: Re: review printing ecpg program version