Lo que no sabías que se puede hacer con el fichero de configuración postgresql.conf

El fichero de configuración de PostgreSQL contiene alrededor de 280 parámetros distintos con los que configuramos distintos elementos del motor de bases de datos agrupados en secciones (FILE LOCATIONS, CONNECTIONS AND AUTHENTICATION, RESOURCE USAGE, QUERY TUNING, etc.)

Al final del fichero hay dos secciones sin parámetros y en este artículo vamos a desvelar para qué sirven.

# ——————————————————————————
# CONFIG FILE INCLUDES
# ——————————————————————————

En esta sección podemos declarar tres tipos de directivas que podemos usar más de una vez.

Con estas directivas le decimos al servidor PostgreSQL los ficheros de configuración adicionales que tiene que leer.

Estas son:

include

Le decimos el nombre de un fichero que contendrá parámetros de configuración adicionales.

Por ejemplo:

include = ‘filename.conf’

include_if_exists

Le decimos que cargue los parámetros incluidos en el ficheros adicional, si existe.

En este caso, si el fichero no existe no dará error.

include_dir

Si tenemos una serie de ficheros de configuración adicionales en la misma ubicación podemos indicarle al servidor PostgreSQL la ruta en la que se encuentran y los leerá todos sin necesidad de especificarlos uno a uno con las otras directivas.

La utilidad que hace muy interesante esta sección es que podemos ir variando la configuración del servidor según las necesidad.

Con un ejemplo se entenderá mejor.

Imagina que tienes un servidor PostgreSQL con una determinada configuración de los parámetros relacionados con el autovacuum pero llegas a la conclusión de que esa configuración es óptima a determinadas horas del día pero que a otras horas, por ejemplo en la madrugada, sería más óptimo otra configuración que aprovechase la baja actividad del servidor durante la madrugada para realizar las tareas de mantenimiento de la base de datos.

Pensarás en programar un script de comandos ALTER SYSTEM para asignar unos valores a esos parámetros y que se ejecutará cada día, a través del cron, a las 0 horas y otro script de comandos ALTER SYSTEM que devuelva los valores actuales a dichos parámetros y que se ejecutará también, a través del cron, a las 8:00 horas.

Es una opción desde luego pero hay otra más elegante quizás, y más cómoda de mantener, que consistiría en jugar a nuestro interés con estas directivas.

Para el ejemplo anterior yo tendría dos ficheros de configuración que llamaría autovacuum_soft.conf, con la configuración «suave» de los parámetros para que el mantenimiento del servidor no afecte al rendimiento del sistema en sus horas de mayor actividad, y autovacuum_hard.conf con la configuración que permita un mayor actividad de mantenimiento del servidor y, de entre las múltiples opciones que podría implementar elegiría indistintamente una de ellas. Os indico dos posibles opciones a modo de ejemplo:

include = ‘autovacuum.conf’

Utilizaría en el fichero de configuración postgresql.conf la directiva include y programaría un cron similar a:

0 0 * * * cp autovacuum_hard.conf autovacuum.conf

0 8 * * * cp autovacuum_soft.conf autovacuum.conf

Seguido por un reload (o restart) del servidor, dependiendo de los parámetros que queremos modificar.

include_dir = ‘/var/lib/pgsql/autovacuum_conf/’

Utilizaría en el fichero de configuración postgresql.conf la directiva include_dir y programaría un cron similiar a:

0 0 * * * cp autovacuum_hard.conf /var/lib/pgsql/autovacuum_conf/autovacuum.conf

0 8 * * * cp autovacuum_soft.conf /var/lib/pgsql/autovacuum_conf/autovacuum.conf

Seguido por un reload, o por un restart, dependiendo de los parámtros que queremos modificar.

# ——————————————————————————
# CUSTOMIZED OPTIONS
# ——————————————————————————

Esta sección fue diseñada para agrupar los parámetros que provienen de módulos externos a PostgreSQL como es el caso de algunas extensiones, de manera que los parámetros van precedidos por un prefijo.

prefijo.parametro = valor

PostgreSQL aceptará cualquier parámetro especificado de esta forma y será la extensión quién se encargue de reconocer el parámetro, interpretarlo, o emitir un mensaje de error si no está bien definido.

Esto nos abre una posibilidad adicional a los DBAs pues nos permite tener parámetros propios en cada servidor para usarlos en nuestros scripts o cuando queremos proporcionar alguna clase de metadatos sobre nuestro cluster.