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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Regression tests failing if not launched on db "regression"
Дата
Msg-id CA+TgmoZBJK2z5vnewKRQS1jNoirNXOL_1TBkNHhL8a+N-729Tg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Regression tests failing if not launched on db "regression"  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Regression tests failing if not launched on db "regression"  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
<michael.paquier@gmail.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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Recovery inconsistencies, standby much larger than primary
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Recovery inconsistencies, standby much larger than primary