Para ejecutar las pruebas de regresión en paralelo después de compilar pero antes de instalar, escribe:

make check

en el directorio de nivel superior. (O puedes cambiar a src/test/regress y ejecutar el comando allí). Las pruebas que se ejecutan en paralelo tienen el prefijo “+”, y las pruebas que se ejecutan secuencialmente tienen el prefijo “-”. Al final deberías ver algo como:

# All 213 tests passed.

o de lo contrario una nota sobre qué pruebas fallaron. Consulta Section 31.2 más abajo antes de asumir que un “fallo” representa un problema serio.

Debido a que este método de prueba ejecuta un servidor temporal, no funcionará si realizaste la compilación como el usuario root, ya que el servidor no se iniciará como root. El procedimiento recomendado es no realizar la compilación como root, o bien realizar las pruebas después de completar la instalación.

Si has configurado PostgreSQL para instalarse en una ubicación donde ya existe una instalación anterior de PostgreSQL, y ejecutas make check antes de instalar la nueva versión, podrías encontrar que las pruebas fallan porque los nuevos programas intentan usar las bibliotecas compartidas ya instaladas. (Los síntomas típicos son quejas sobre símbolos no definidos). Si deseas ejecutar las pruebas antes de sobrescribir la instalación anterior, necesitarás compilar con configure --disable-rpath. Sin embargo, no se recomienda utilizar esta opción para la instalación final.

La prueba de regresión en paralelo inicia bastantes procesos bajo tu ID de usuario. Actualmente, la concurrencia máxima es de veinte scripts de prueba paralelos, lo que significa cuarenta procesos: hay un proceso de servidor y un proceso de psql para cada script de prueba. Por lo tanto, si tu sistema impone un límite por usuario en el número de procesos, asegúrate de que este límite sea de al menos unos cincuenta; de lo contrario, podrías obtener fallos que parecen aleatorios en la prueba en paralelo. Si no estás en condiciones de aumentar el límite, puedes reducir el grado de paralelismo configurando el parámetro MAX_CONNECTIONS. Por ejemplo:

make MAX_CONNECTIONS=10 check

ejecuta no más de diez pruebas concurrentemente.

Para ejecutar las pruebas después de la instalación (consulta Chapter 17), inicializa un directorio de datos e inicia el servidor como se explica en Chapter 18, luego escribe:

make installcheck

o para una prueba en paralelo:

make installcheck-parallel

Las pruebas esperarán contactar al servidor en el host local y en el número de puerto por defecto, a menos que se indique lo contrario mediante las variables de entorno PGHOST y PGPORT. Las pruebas se ejecutarán en una base de datos llamada regression; cualquier base de datos existente con este nombre será eliminada.

Las pruebas también crearán transitoriamente algunos objetos a nivel de clúster, como roles, tablespaces y suscripciones. Estos objetos tendrán nombres que comiencen con regress_. Ten cuidado al usar el modo installcheck con una instalación que tenga algún objeto global real con ese nombre.

Los comandos make check y make installcheck ejecutan únicamente las pruebas de regresión “principales” (core), que prueban la funcionalidad incorporada del servidor PostgreSQL. La distribución de código fuente contiene muchas suites de pruebas adicionales, la mayoría de ellas relacionadas con la funcionalidad complementaria (add-on), como los lenguajes procedimentales opcionales.

Para ejecutar todas las suites de pruebas aplicables a los módulos que se han seleccionado para ser compilados, incluyendo las pruebas principales, escribe uno de estos comandos en la raíz del árbol de compilación:

make check-world
make installcheck-world

Estos comandos ejecutan las pruebas utilizando servidores temporales o un servidor ya instalado, respectivamente, tal como se explicó anteriormente para make check y make installcheck. Otras consideraciones son las mismas que se explicaron anteriormente para cada método. Ten en cuenta que make check-world compila una instancia separada (directorio de datos temporal) para cada módulo probado, por lo que requiere más tiempo y espacio en disco que make installcheck-world.

En una máquina moderna con múltiples núcleos de CPU y sin límites estrictos del sistema operativo, puedes hacer que las cosas vayan sustancialmente más rápido con paralelismo. La receta que la mayoría de los desarrolladores de PostgreSQL utilizan actualmente para ejecutar todas las pruebas es algo como

make check-world -j8 >/dev/null

con un límite de -j cercano o un poco superior al número de núcleos disponibles. Descartar la salida estándar (stdout) elimina el ruido que no es interesante cuando solo deseas verificar el éxito. (En caso de fallo, los mensajes de error estándar (stderr) suelen ser suficientes para determinar dónde buscar más de cerca).

Alternativamente, puedes ejecutar suites de pruebas individuales escribiendo make check o make installcheck en el subdirectorio correspondiente del árbol de compilación. Ten en cuenta que make installcheck asume que has instalado el módulo o módulos correspondientes, no solo el servidor principal.

Las pruebas adicionales que se pueden invocar de esta manera incluyen:

Al utilizar el modo installcheck, estas pruebas crearán y destruirán bases de datos de prueba cuyos nombres incluyen regression, por ejemplo pl_regression o contrib_regression. Ten cuidado al usar el modo installcheck con una instalación que tenga bases de datos que no sean de prueba con ese nombre.

Algunas de estas suites de pruebas auxiliares utilizan la infraestructura TAP explicada en la Section 31.4. Las pruebas basadas en TAP se ejecutan solo cuando PostgreSQL se configuró con la opción --enable-tap-tests. Esto se recomienda para el desarrollo, pero se puede omitir si no existe una instalación de Perl adecuada.

Algunas suites de pruebas no se ejecutan por defecto, ya sea porque no es seguro ejecutarlas en un sistema multiusuario, porque requieren software especial o porque son muy intensivas en recursos. Puedes decidir qué suites de pruebas ejecutar adicionalmente configurando la variable de entorno o de make PG_TEST_EXTRA con una lista separada por espacios en blanco, por ejemplo:

make check-world PG_TEST_EXTRA='kerberos ldap ssl load_balance libpq_encryption'

Actualmente se admiten los siguientes valores:

Las pruebas de características que no son soportadas por la configuración de compilación actual no se ejecutan incluso si se mencionan en PG_TEST_EXTRA.

Además, existen pruebas en src/test/modules que serán ejecutadas por make check-world pero no por make installcheck-world. Esto se debe a que instalan extensiones que no son de producción o tienen otros efectos secundarios que se consideran indeseables para una instalación de producción. Puedes usar make install y make installcheck en uno de esos subdirectorios si lo deseas, pero no se recomienda hacerlo con un servidor que no sea de prueba.

Por defecto, las pruebas que utilizan una instalación temporal usan la configuración regional (locale) definida en el entorno actual y la codificación de base de datos correspondiente determinada por initdb. Puede ser útil probar diferentes configuraciones regionales estableciendo las variables de entorno adecuadas, por ejemplo:

make check LANG=C
make check LC_COLLATE=en_US.utf8 LC_CTYPE=fr_CA.utf8

Por razones de implementación, establecer LC_ALL no funciona para este propósito; todas las demás variables de entorno relacionadas con la configuración regional sí funcionan.

Al realizar las pruebas contra una instalación existente, la configuración regional se determina por el clúster de base de datos existente y no se puede establecer por separado para la ejecución de la prueba.

También puedes elegir la codificación de la base de datos explícitamente estableciendo la variable ENCODING, for ejemplo:

make check LANG=C ENCODING=EUC_JP

Establecer la codificación de la base de datos de esta manera normalmente solo tiene sentido si la configuración regional es C; de lo contrario, la codificación se elige automáticamente a partir de la configuración regional, y especificar una codificación que no coincida con la configuración regional provocará un error.

La codificación de la base de datos se puede establecer para pruebas tanto contra una instalación temporal como existente, aunque en este último caso debe ser compatible con la configuración regional de la instalación.

Existen varias formas de utilizar configuraciones de servidor personalizadas al ejecutar una suite de pruebas. Esto puede ser útil para habilitar registros adicionales, ajustar límites de recursos, o habilitar comprobaciones adicionales en tiempo de ejecución como debug_discard_caches. Pero ten en cuenta que no se puede esperar que todas las pruebas pasen limpiamente con configuraciones arbitrarias.

Se pueden pasar opciones adicionales a los diversos comandos initdb que se ejecutan internamente durante la configuración de la prueba utilizando la variable de entorno PG_TEST_INITDB_EXTRA_OPTS. Por ejemplo, para ejecutar una prueba con sumas de comprobación (checksums) habilitadas, un tamaño de segmento WAL personalizado y la configuración work_mem, utiliza:

make check PG_TEST_INITDB_EXTRA_OPTS='-k --wal-segsize=4 -c work_mem=50MB'

Para la suite de pruebas de regresión principal y otras pruebas dirigidas por pg_regress, también se pueden establecer configuraciones de servidor personalizadas en tiempo de ejecución en la variable de entorno PGOPTIONS (para configuraciones que lo permitan), por ejemplo:

make check PGOPTIONS="-c debug_parallel_query=regress -c work_mem=50MB"

(Esto hace uso de la funcionalidad proporcionada por libpq; consulta la options para más detalles).

Cuando se ejecuta contra una instalación temporal, las configuraciones personalizadas también se pueden establecer proporcionando un archivo postgresql.conf preescrito:

echo 'log_checkpoints = on' > test_postgresql.conf
echo 'work_mem = 50MB' >> test_postgresql.conf
make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf"

La suite de pruebas de regresión principal contiene algunos archivos de prueba que no se ejecutan por defecto, porque podrían ser dependientes de la plataforma o tardar mucho tiempo en ejecutarse. Puedes ejecutar estos u otros archivos de prueba adicionales configurando la variable EXTRA_TESTS. Por ejemplo, para ejecutar la prueba numeric_big:

make check EXTRA_TESTS=numeric_big