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-01-31 15:42:57
Message-ID: CA+TgmoZBJK2z5vnewKRQS1jNoirNXOL_1TBkNHhL8a+N-729Tg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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

Attachment Content-Type Size
regressdoc.patch text/x-patch 1.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2014-01-31 15:43:09 Re: Recovery inconsistencies, standby much larger than primary
Previous Message Tom Lane 2014-01-31 15:41:48 Re: Recovery inconsistencies, standby much larger than primary