Оценка тестов
Эта страница переведена при помощи нейросети GigaChat.
Некоторые корректно установленные и полностью функциональные экземпляры PostgreSQL могут «не пройти» некоторые из этих регрессионных тестов из-за специфичных для платформы артефактов, таких как различное представление чисел с плавающей запятой и формулировка сообщений. В настоящее время тесты оцениваются путем простого сравнения с выходными данными, сгенерированными на эталонной системе, поэтому результаты чувствительны к небольшим системным различиям. Когда тест определяется как «неудачный», всегда анализируйте различия между ожидаемыми и фактическими результатами; можно обнаружить, что эти различия не являются значительными. Прилагаются усилия для поддержания точных справочных файлов на всех поддерживаемых платформах, так что можно ожидать, что все тесты пройдут.
Фактические выходные данные регрессионных тестов находятся в файлах в каталоге src/test/regress/results. Скрипт теста использует diff для сравнения каждого файла вывода со справочными выходными данными, хранящимися в каталоге src/test/regress/expected. Все различия сохраняются для просмотра в src/test/regress/regression.diffs (когда выполняется набор тестов, отличный от основных тестов, эти файлы появляются в соответствующем подкаталоге, а не в src/test/regress).
Если необходимо изменить параметры diff, которые используются по умолчанию, установите переменную среды PG_REGRESS_DIFF_OPTS, например PG_REGRESS_DIFF_OPTS='-c' (существует возможность запустить diff самостоятельно).
Если по какой-то причине конкретная платформа генерирует «неудачу» для определенного теста, но проверка вывода убеждает, что результат действителен, добавьте новый файл сравнения, чтобы заглушить отчет об ошибке при будущих запусках тестов. См. раздел «Файлы сравнения вариантов» для получения подробной информации.
Различия сообщений об ошибках
Некоторые регрессионные тесты включают преднамеренные недопустимые входные значения. Сообщения об ошибках могут исходить либо от кода PostgreSQL, либо от системных процедур хост-платформы. В последнем случае сообщения могут различаться между платформами, но должны отражать аналогичную информацию. Эти различия в сообщениях приведут к «неудачному» регрессионному тесту, который можно подтвердить путем проверки.
Локальные различия
При запуске тестов на сервере, инициализированном с порядком сортировки локали, отличным от C, могут быть различия из-за порядка сортировки и последующих сбоев. Набор тестов регрессии настроен для решения этой проблемы за счет предоставления альтернативных файлов результатов, которые, как известно, вместе могут обрабатывать большое количество локалей.
Чтобы запустить тесты в другой локали при использовании метода временной установки, передайте соответствующие переменные окружения, связанные с локалью, в командной строке, например:
make check LANG=de_DE.utf8
Драйвер тестирования регрессии снимает LC_ALL, поэтому выбор локали с помощью этой переменной не работает. Чтобы использовать локаль по умолчанию, либо сбросьте все связанные с локалью переменные окружения (или установите их на C), либо используйте следующую специальную команду:
make check NO_LOCALE=1
При запуске тестов на существующей установке настройка локали определяется этой существующей установкой. Чтобы изменить это, инициализируйте кластер баз данных с другой локалью, передав соответствующие параметры в initdb.
В общем случае рекомендуется попытаться запустить тесты регрессии в настройке локали, которая будет использоваться для производственного использования, поскольку это позволит задействовать части кода, относящиеся к локали и кодировке, которые будут фактически использоваться в производстве. В зависимости от операционной среды можно получить сбои, но тогда будет известно, какого поведения, специфичного для локали, следует ожидать при запуске реальных приложений.
Различия во времени и дате
Большинство результатов даты и времени зависят от среды часового пояса. Справочные файлы создаются для часового пояса America/los Angeles, поэтому будут очевидные сбои, если тесты не запускаются с этой настройкой часового пояса. Драйвер регрессионного тестирования устанавливает переменную окружения PGTZ на America/Los Angeles, что обычно обеспечивает правильные результаты.
Различия с плавающей точкой
Некоторые из тестов включают расчет чисел с плавающей точкой длиной 64 бита (double precision) из столбцов таблицы. Были замечены различия в результатах, включающих математические функции столбцов double precision. Тесты float8 и geometry особенно подвержены небольшим различиям между платформами или даже при различных настройках оптимизации компилятора. Сравнение человеческим глазом необходимо для определения реальной значимости этих различий, которые обычно находятся на десять позиций справа от десятичной точки.
Некоторые системы отображают минус ноль как -0, а другие просто показывают 0.
Некоторые системы сигнализируют об ошибках из pow() и exp() иначе, чем механизм, ожидаемый текущим кодом PostgreSQL.
Различия в порядке строк
Можно увидеть различия в том, что одни и те же строки выводятся в порядке, отличном от того, который отображается в ожидаемом файле. В большинстве случаев это не является, строго говоря, ошибкой. Большинство сценариев регрессионного тестирования не настолько педантичны, чтобы использовать ORDER BY для каждого отдельного SELECT, поэтому порядок их результирующих строк не определен в соответствии со спецификацией SQL. На практике, поскольку внимание направлено на выполнение одних и тех же запросов с одними и теми же данными одним и тем же программным обеспечением, обычно получаем один и тот же порядок результатов на всех платформах, так что отсутствие ORDER BY не является проблемой. Однако некоторые запросы действительно демонстрируют межплатформенные различия в порядке. При тестировании уже установленного сервера различия в порядке могут быть вызваны настройками локали, отличными от C, или параметрами, отличающимися от настроек по умолчанию, такими как пользовательские значения work_mem или параметры стоимости планировщика.
Поэтому, если заметна разница в порядке, не стоит беспокоиться об этом, если только запрос действительно имеет ORDER BY, который нарушает результат. Тем не менее, пожалуйста, сообщите об этом, чтобы была возможность добавить ORDER BY к этому конкретному запросу, чтобы исключить ложное «неудача» в будущих выпусках.
Все запросы регрессионных тестов не упорядочены явно, чтобы раз и навсегда избавиться от этой проблемы. Причина такого решения заключается в том, что это сделало бы регрессионные тесты менее полезными, поскольку они имели бы тенденцию выполнять типы планов запросов, выдающие упорядоченные результаты, за исключением тех запросов, которые этого не делают.
Недостаточная глубина стека
Если тест приводит к сбою сервера при выполнении команды select infinite_recurse(), это означает, что ограничение платформы на размер стека процесса меньше, чем указано параметром max_stack_depth. Это можно исправить, запустив сервер с большим пределом размера стека (рекомендуется 4 МБ со значением по умолчанию max_stack_depth). Альтернативой такого способа является уменьшение значения max_stack_depth.
На платформах, поддерживающих getrlimit(), сервер должен автоматически выбирать безопасное значение для max_stack_depth; поэтому, если вручную не переопределить эту настройку, сбой такого рода является ошибкой, о которой следует сообщить.
Тест random
Сценарий теста random предназначен для получения случайных результатов. В очень редких случаях это приводит к тому, что регрессионный тест завершается неудачно. Набрав:
diff results/random.out expected/random.out
должно появиться только одна или несколько строк различий. Не нужно беспокоиться в случае, если случайный тест терпит неудачу повторно.
Параметры конфигурации
При запуске тестов на существующей установке некоторые нестандартные настройки параметров могут привести к сбою тестов. Например, изменение таких параметров, как enable_seqscan или enable_indexscan, может вызвать изменения плана, которые повлияют на результаты тестов, использующих EXPLAIN.