Subject: Re: make installcheck-world in a clean environment
To: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: <bfee872b-ab16-ec7c-8f8a-b3949add1c1b@gmail.com>
 <CA+TgmoafXiYMj6ROd09PxLFQ_dpurP1FJOL4ZwDonCkPeSubWg@mail.gmail.com>
 <aff02bd6-20c9-0b6e-4e3c-a3428ce6568b@gmail.com>
 <CA+TgmoZV08_6SXmag0hFkOurgWPjks6Jwyh+DeFXsCxLWLVjfw@mail.gmail.com>
 <24834.1525712835@sss.pgh.pa.us> <20180912072049.GL25160@paquier.xyz>
From: Alexander Lakhin <exclusion@gmail.com>
Message-ID: <171724bb-0436-3665-6738-cbd42bdf9783@gmail.com>
Date: Wed, 12 Sep 2018 11:26:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180912072049.GL25160@paquier.xyz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

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