Re: Regression tests failing if not launched on db "regression"

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Christian Kruse <christian(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Regression tests failing if not launched on db "regression"
Date: 2014-02-03 15:49:44
Message-ID: CA+TgmoaDJ5BzN+=hbjGj6Wx3+1EBn23hZyT5SuhOvA+DJm=kAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 31, 2014 at 5:48 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Sat, Feb 1, 2014 at 12:42 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>>> I took a look at this with a view to committing it but on examination
>>>> I'm not sure this is the best way to proceed. The proposed text
>>>> documents that the tests should be run in a database called
>>>> regression, but the larger documentation chapter of which this section
>>>> is a part never explains how to run them anywhere else, so it feels a
>>>> bit like telling a ten-year-old not to burn out the clutch.
>>>>
>>>> The bit about not changing enable_* probably belongs, if anywhere, in
>>>> section 30.2, on test evaluation, rather than here.
>>> And what about the attached? I have moved all the content to 30.2, and
>>> added two paragraphs: one about the planner flags, the other about the
>>> database used.
>>> Regards,
>>
>> Well, it doesn't really address my first concern, which was that you
>> talk about running the tests in a database named regression, but
>> that's exactly what "make check" does and it's unclear how you would
>> do anything else without modifying the source code. It's not the
>> purpose of the documentation to tell you all the ways that you could
>> break things if you patch the tree. I also don't want to document
>> exactly which tests would fail if you did hack things like that; that
>> documentation is likely to become outdated.
>>
>> I think the remaining points you raise are worth mentioning. I'm
>> attaching a patch with my proposed rewording of your changes. I made
>> the section about configuration parameters a bit more generic and
>> adjusted the phrasing to sound more natural in English, and I moved
>> your mention of the other issues around a bit. What do you think of
>> this version?
> The part about the planning parameter looks good, thanks. The places
> used to mention the databases used also makes more sense. Thanks for
> your input.

OK, committed and back-patched to 9.3.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2014-02-03 16:02:07 Re: KNN-GiST with recheck
Previous Message Robert Haas 2014-02-03 15:49:30 pgsql: Document a few more regression test hazards.