Quelques installations de PostgreSQL
proprement installées et totalement fonctionnelles peuvent
« échouer » sur certains des tests de régression à cause de
certains points spécifiques à la plateforme comme une représentation de
nombres à virgules flottantes ou « message wording ». Les tests
sont actuellement évalués en utilisant une simple comparaison
diff
avec les sorties générées sur un système de
référence, donc les résultats sont sensibles aux petites différences
système. Quand un test est rapporté comme « échoué », toujours
examiner les différences entre les résultats attendus et ceux obtenus ;
vous pourriez très bien trouver que les différences ne sont pas significatives.
Néanmoins, nous nous battons toujours pour maintenir des fichiers de
références précis et à jour pour toutes les plateformes supportés de façon à
ce que tous les tests puissent réussir.
Les sorties actuelles des tests de régression sont dans les fichiers du
répertoire src/test/regress/results
. Le script de test
utilise diff
pour comparer chaque fichier de sortie avec
les sorties de référence stockées dans le répertoire
src/test/regress/expected
. Toutes les différences sont
conservées pour que vous puissiez les regarder dans
src/test/regress/regression.diffs
. (Lors de l'exécution
d'une suite de tests en dehors des tests internes, ces fichiers doivent
apparaître dans le sous-répertoire adéquat, mais pas
src/test/regress
.)
Si vous n'aimez pas
les options utilisées par défaut pour la commande diff
,
configurez la variable d'environnement PG_REGRESS_DIFF_OPTS
.
Par exemple PG_REGRESS_DIFF_OPTS='-u'
(ou vous pouvez
lancer diff
vous-même, si vous préférez).
Si, pour certaines raisons, une plateforme particulière génère un « échec » pour un test donné mais qu'une revue de la sortie vous convaint que le résultat est valide, vous pouvez ajouter un nouveau fichier de comparaison pour annuler le rapport d'échec pour les prochains lancements du test. Voir la Section 33.3 pour les détails.
Certains des tests de régression impliquent des valeurs en entrée intentionnellement invalides. Les messages d'erreur peuvent provenir soit du code de PostgreSQL soit des routines système de la plateforme hôte. Dans ce dernier cas, les messages pourraient varier entre plateformes mais devraient toujours refléter des informations similaires. Ces différences dans les messages résulteront en un échec du test de régression qui pourrait être validé après vérification.
Si vous lancez des tests sur un serveur initialisé avec une locale autre que C, alors il pourrait y avoir des différences dans les ordres de tris. La suite de tests de régression est initialisée pour gérer ce problème en fournissant des fichiers de résultats alternatifs qui gèrent ensemble un grand nombre de locales.
Pour exécuter les tests dans une locale différente lors de l'utilisation
de la méthode d'installation temporaire, passez les variables d'environnement
relatives à la locale sur la ligne de commande de
make
, par exemple :
make check LANG=de_DE.utf8
(Le pilote de tests des régressions déconfigure LC_ALL
,
donc choisir la locale par cette variable ne fonctionne pas.) Pour
ne pas utiliser de locale, vous devez soit déconfigurer toutes les
variables d'environnement relatives aux locales (ou les configurer à
C
) ou utiliser une option spéciale :
make check NO_LOCALE=1
Lors de l'exécution des tests sur une installation existante, la
configuration de la locale est déterminée d'après l'installation
existante. Pour la modifier, initialiser le cluster avec une locale
différente en passant les options appropriées à initdb
.
En général, il est conseillé d'essayer l'exécution des tests de régression dans la configuration de locale souhaitée pour l'utilisation en production, car cela testera aussi les portions de code relatives à l'encodage et à la locale qui pourront être utilisées en production. Suivant l'environnement du système d'exploitation, vous pourrez obtenir des échecs, mais vous saurez au moins le comportement à attendre sur la locale lorsque vous utiliserez vos vraies applications.
La plupart des résultats date/heure sont dépendants de l'environnement
de zone horaire. Les fichiers de référence sont générés pour la zone
horaire PST8PDT
(Berkeley, Californie), et il y aura
des échecs apparents si les tests ne sont pas lancés avec ce paramétrage de
fuseau horaire. Le pilote des tests de régression initialise la variable
d'environnement PGTZ
à PST8PDT
ce qui
nous assure normalement de bons résultats.
Quelques tests impliquent des calculs sur des nombres flottants à 64 bits
(double precision
) à partir de colonnes de tables. Des
différences dans les résultats appliquant des fonctions mathématiques à des
colonnes double precision
ont été observées. Les tests de
float8
et geometry
sont particulièrement sensibles
aux différences entre plateformes, voire aux différentes options
d'optimisation des compilateurs. L'œil humain
est nécessaire pour déterminer la véritable signification de ces différences,
habituellement situées après la dixième décimale.
Certains systèmes affichent moins zéro comme -0
alors que
d'autres affichent seulement 0
.
Certains systèmes signalent des erreurs avec pow()
et
exp()
différemment suivant le mécanisme attendu du
code de PostgreSQL.
Vous pourriez voir des différences dans lesquelles les mêmes lignes sont
affichées dans un ordre différent de celui qui apparaît dans le fichier de
référence. Dans la plupart des cas, ce n'est pas à strictement parlé un
bogue. La plupart des scripts de tests de régression ne sont pas assez
stricts pour utiliser un ORDER BY
sur chaque
SELECT
et, du coup, l'ordre des lignes pourrait ne pas être
correctement défini suivant la spécification SQL. En pratique, comme nous
sommes avec les mêmes requêtes sur les mêmes données avec le même logiciel,
nous obtenons habituellement le même résultat sur toutes les plateformes et
le manque d'ORDER BY
n'est pas un problème. Quelques requêtes
affichent des différences d'ordre entre plateformes. Lors de tests avec un
serveur déjà installé, les différences dans l'ordre des lignes peuvent
aussi être causées par un paramètrage des locales à une valeur différente
de C ou par un paramètrage personnalisé, comme des valeurs personnalisées
de work_mem
ou du coût du planificateur.
Du coup, si vous voyez une différence dans l'ordre, vous n'avez pas à vous
inquiéter sauf si la requête possède un ORDER BY
que votre
résultat ne respecte pas. Néanmoins, rapportez tout de même ce problème que nous
ajoutions un ORDER BY
à cette requête pour éliminer les faux
« échecs » dans les versions suivantes.
Vous pourriez vous demander pourquoi nous n'ordonnons pas toutes les requêtes des tests de régression explicitement pour supprimer ce problème une fois pour toutes. La raison est que cela rendrait les tests de régression moins utiles car ils tendraient à exercer des types de plans de requêtes produisant des résultats ordonnés à l'exclusion de celles qui ne le font pas.
Si les tests d'erreurs
se terminent avec un arrêt
brutal du serveur pendant la commande select
infinite_recurse()
, cela signifie que la limite de la plateforme pour
la taille de pile du processus est plus petite que le paramètre
max_stack_depth
ne l'indique. Ceci est corrigeable
en exécutant le postmaster avec une limite pour la taille de pile plus
importante (4 Mo est recommandé avec la valeur par défaut de
max_stack_depth
). Si vous n'êtes pas capables de le faire, une
alternative est de réduire la valeur de max_stack_depth
.
Sur les plateformes supportant getrlimit()
, le serveur
devrait choisir automatiquement une valeur sûre pour
max_stack_depth
; donc, à moins de surcharger
manuellement ce paramètre, un échec de ce type est un bug à reporter.
Le script de tests random
a pour but de produire
des résultats aléatoires. Dans de très rares cas, ceci fait échouer random
aux tests de régression. Saisir :
diff results/random.out expected/random.out
ne devrait produire au plus que quelques lignes différentes. Cela est normal et ne devient préoccupant que si les tests random échouent en permanence lors de tests répétés
Lors de l'exécution de tests contre une installation existante, certains
paramètres configurés à des valeurs spécifiques pourraient causer l'échec
des tests. Par exemple, modifier des paramètres comme
enable_seqscan
ou enable_indexscan
pourrait être la cause de changements de plan affectant le résultat des
tests qui utilisent EXPLAIN
.