From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: make installcheck-world in a clean environment |
Date: | 2018-09-12 08:26:00 |
Message-ID: | 171724bb-0436-3665-6738-cbd42bdf9783@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ioseph Kim | 2018-09-12 08:32:24 | Re: review printing ecpg program version |
Previous Message | Christoph Berg | 2018-09-12 08:15:48 | Re: Collation versioning |