Re: tuplesort test coverage

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: tuplesort test coverage
Дата
Msg-id 20446.1576353803@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: tuplesort test coverage  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-12-12 09:27:04 -0500, Tom Lane wrote:
>> What seems like a simpler and more reliable fix is to make
>> test_mark_restore a temp table, thus keeping autovac away from it.
>> Is there a reason in terms of the test's goals not to do that?

> I can't see any reason. The sorting code shouldn't care about the source
> of tuples. I guess there could at some point be tests for parallel
> sorting, but that'd just use a different table.

OK, done that way.

>> Also ... why in the world does the script drop its tables at the end
>> with IF EXISTS?  They'd better exist at that point.  I object
>> to the DROP IF EXISTS up at the top, too.  The regression tests
>> do not need to be designed to deal with an unpredictable start state,
>> and coding them to do so can have no effect other than possibly
>> masking problems.

> Well, it makes it a heck of a lot easier to run tests in isolation while
> evolving them. While I personally think it's good to leave cleanup for
> partial states in for cases where it was helpful during development, I
> also don't care about it strongly.

As far as that goes, making the tables temp is an even better solution.

            regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Memory-Bounded Hash Aggregation
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] proposal: schema variables