tuplesort test coverage

Поиск
Список
Период
Сортировка
От Andres Freund
Тема tuplesort test coverage
Дата
Msg-id 20191013144153.ooxrfglvnaocsrx2@alap3.anarazel.de
обсуждение исходный текст
Ответы Re: tuplesort test coverage  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
Hi,

[1] made me look at tuplesorts test coverage at
https://coverage.postgresql.org/src/backend/utils/sort/tuplesort.c.gcov.html
We don't have coverage for a quite a number of things:
- cluster for expression indexes (line 935)
- sorts exceeding INT_MAX / 2 memory (line 1337), but that seems hard to
  test realistically
- aborted abbreviated keys (lines 1522, 1608, 1774, 3620, 3739, 3867, 4266)
- in memory backwards scans (lines 1936, 3042)
- *any* coverage for TSS_SORTEDONTAPE (line 1964)
- disk sort skiptuples (line 2325)
- mergeruns without abbrev key (line 2582)
- disk sorts with more than one run (lines 2707, 2789)
- any disk based tuplesort_begin_heap() (lines 3649, 3676)
- Seems copytup_index currently is essentially dead, because
  tuplesort_putindextuplevalues() doesn't use COPYTUP (line 4142)
- any disk based tuplesort_begin_datum (lines 4282, 4323)

I'm pretty unhappy that tuplesort has been whacked around pretty heavily
in the last few years, while *reducing* effective test coverage
noticeably, rather than increasing it.  There's pretty substantial and
nontrivial areas without any tests - do we have actually have any
confidence that they work?

The largest culprits for that seem to be abbreviated keys, the tape
logic overhaul, and the increase of work mem.

Greetings,

Andres Freund



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: stress test for parallel workers
Следующее
От: Andres Freund
Дата:
Сообщение: Re: stress test for parallel workers