Algunas de las pruebas de regresión implican valores de entrada inválidos de manera intencionada. Los mensajes de error pueden provenir tanto del código de PostgreSQL como de las rutinas del sistema de la plataforma anfitriona. En este último caso, los mensajes pueden variar entre plataformas, pero deberían reflejar información similar. Estas diferencias en los mensajes darán como resultado una prueba de regresión “fallida” que puede ser validada mediante inspección.

Si ejecutas las pruebas contra un servidor que fue inicializado con una configuración regional de ordenación (collation) distinta de C, entonces podría haber diferencias debido al orden de clasificación y consecuentes fallos. La suite de pruebas de regresión está configurada para manejar este problema proporcionando archivos de resultados alternativos que en conjunto se sabe que manejan una gran cantidad de configuraciones regionales.

Para ejecutar las pruebas en una configuración regional diferente cuando utilices el método de instalación temporal, pasa las variables de entorno relacionadas con la configuración regional en la línea de comandos de make, por ejemplo:

make check LANG=de_DE.utf8

(El controlador de pruebas de regresión desactiva la variable LC_ALL, por lo que no funciona elegir la configuración regional utilizando esa variable). Para no utilizar ninguna configuración regional, desactiva todas las variables de entorno relacionadas con ella (o establécelas en C) o utiliza la siguiente invocación especial:

make check NO_LOCALE=1

Al ejecutar las pruebas contra una instalación existente, la configuración de la configuración regional la determina la instalación existente. Para cambiarla, inicializa el clúster de base de datos con una configuración regional diferente pasando las opciones correspondientes a initdb.

En general, es aconsejable intentar ejecutar las pruebas de regresión en la configuración regional que se desee para el uso en producción, ya que esto ejercitará las porciones de código relacionadas con la configuración regional y la codificación que realmente se utilizarán en producción. Dependiendo del entorno del sistema operativo, podrías obtener fallos, pero al menos sabrás qué comportamientos específicos de la configuración regional esperar al ejecutar aplicaciones reales.

La mayoría de los resultados de fecha y hora dependen del entorno de la zona horaria. Los archivos de referencia se generan para la zona horaria America/Los_Angeles, y habrá fallos aparentes si las pruebas no se ejecutan con esa configuración de zona horaria. El controlador de pruebas de regresión establece la variable de entorno PGTZ en America/Los_Angeles, lo que normalmente asegura resultados correctos.

Algunas de las pruebas implican calcular números de punto flotante de 64 bits (double precision) a partir de columnas de tablas. Se han observado diferencias en los resultados que involucran funciones matemáticas de columnas double precision. Las pruebas de float8 y geometry son particularmente propensas a pequeñas diferencias entre plataformas, o incluso con diferentes configuraciones de optimización del compilador. Se necesita una comparación visual humana para determinar la verdadera importancia de estas diferencias, que generalmente se encuentran a partir del décimo dígito a la derecha del punto decimal.

Algunos sistemas muestran el cero negativo como -0, mientras que otros simplemente muestran 0.

Algunos sistemas señalan los errores de pow() y exp() de manera diferente al mecanismo esperado por el código actual de PostgreSQL.

Podrías ver diferencias en las que las mismas filas se devuelven en un orden diferente al que aparece en el archivo esperado. En la mayoría de los casos esto no es, estrictamente hablando, un fallo. La mayoría de los scripts de pruebas de regresión no son tan minuciosos como para usar un ORDER BY para cada uno de los SELECT, por lo que el orden de las filas de sus resultados no está bien definido de acuerdo con la especificación SQL. En la práctica, dado que estamos viendo las mismas consultas ejecutándose en los mismos datos por el mismo software, generalmente obtenemos el mismo orden de resultados en todas las plataformas, por lo que la falta de ORDER BY no suele ser un problema. Sin embargo, algunas consultas sí muestran diferencias de orden entre plataformas. Al realizar las pruebas contra un servidor ya instalado, las diferencias de orden también pueden ser causadas por configuraciones regionales distintas de C o por valores de parámetros no predeterminados, como valores personalizados de work_mem o de los parámetros de costo del planificador.

Por lo tanto, si ves una diferencia en el orden, no es algo por lo que debas preocuparte, a menos que la consulta tenga un ORDER BY que tu resultado esté violando. Sin embargo, por favor repórtalo de todos modos, para que podamos añadir un ORDER BY a esa consulta en particular y eliminar el falso “fallo” en futuras versiones.

Quizás te preguntes por qué no ordenamos explícitamente todas las consultas de las pruebas de regresión para deshacernos de este problema de una vez por todas. La razón es que eso haría que las pruebas de regresión fueran menos útiles, no más, ya que tenderían a ejercitar tipos de planes de consulta que producen resultados ordenados con la exclusión de aquellos que no lo hacen.

Si la prueba de errors resulta en un bloqueo del servidor en el comando select infinite_recurse(), significa que el límite de la plataforma para el tamaño de la pila del proceso es menor de lo que indica el parámetro max_stack_depth. Esto se puede solucionar ejecutando el servidor bajo un límite de tamaño de pila más alto (se recomiendan 4MB con el valor por defecto de max_stack_depth). Si no puedes hacer eso, una alternativa es reducir el valor de max_stack_depth.

En las plataformas que soportan getrlimit(), el servidor debería elegir automáticamente un valor seguro para max_stack_depth; por lo tanto, a menos que hayas sobrescrito manualmente esta configuración, un fallo de este tipo es un error que debe ser reportado.

El script de prueba random está diseñado para producir resultados aleatorios. En casos muy raros, esto hace que esa prueba de regresión fallar. Escribir:

diff results/random.out expected/random.out

debería producir solo una o unas pocas líneas de diferencia. No necesitas preocuparte a menos que la prueba aleatoria falle repetidamente.

Al ejecutar las pruebas contra una instalación existente, algunas configuraciones de parámetros no predeterminadas podrían hacer que las pruebas fallen. Por ejemplo, cambiar parámetros como enable_seqscan o enable_indexscan podría provocar cambios de planes que afectarían los resultados de las pruebas que utilizan EXPLAIN.