Rescatando PostgreSQL - Solución al Error con pg_stat_statements y Optimización del Monitoreo - Capítulo 16

problemas_stat_statements

Instalas PostgreSQL, activas pg_stat_statements y… ¡error fatal!

En este post te cuento cómo solucioné el problema, moví archivos en la ruta correcta y optimicé el monitoreo de consultas SQL. 🚀🔥

Y eso que venía contento del post anterior!

Índice
  1. 🚀 Cuando PostgreSQL no quiere trabajar contigo
  2. 🔍 Diagnóstico del problema: ¿Dónde demonios está pg_stat_statements?
  3. 🛠️ La solución: Hacer que PostgreSQL encuentre lo que busca
    1. ✅ 1. Crear la carpeta de plugins y mover la librería
    2. ✅ 2. Asegurar que PostgreSQL la cargue en cada inicio
    3. ✅ 3. Reiniciar PostgreSQL y verificar el estado
    4. ✅ 4. Crear la extensión dentro de PostgreSQL
  4. 📊 Consultas útiles para monitorear PostgreSQL
    1. 🔥 Listar las 10 consultas más lentas ejecutadas en la base de datos:
    2. 🧹 Resetear las estadísticas de pg_stat_statements:
    3. 🔄 Asegurar que PostgreSQL siempre inicie con pg_stat_statements activo:
  5. 💡 Lo que aprendí en el proceso
  6. 🚀 Conclusión

🚀 Cuando PostgreSQL no quiere trabajar contigo

Todo estaba listo. PostgreSQL 17 instalado en el servidor, consultas funcionando y un optimismo en el aire.

Pero cuando intenté habilitar pg_stat_statements para monitorear el rendimiento de las consultas SQL…

BOOM, error fatal.

FATAL: no se pudo acceder al archivo «$libdir/plugins/pg_stat_statements»: No existe el fichero o el directorio

Nada como un buen error en PostgreSQL para recordarte que la vida del multiapasionado está llena de pequeñas batallas diarias.

Algo no cuadraba!

PostgreSQL no encontraba el módulo necesario para registrar y analizar las consultas.

Y claro, esto había que arreglarlo.


🔍 Diagnóstico del problema: ¿Dónde demonios está pg_stat_statements?

Lo primero fue revisar los logs de PostgreSQL con:

sudo journalctl -u postgresql-17 --no-pager | tail -n 30

Aquí confirmé que PostgreSQL estaba funcionando, pero no encontraba la librería pg_stat_statements.so en la ruta esperada.

Así que probé:

ls /usr/pgsql-17/lib/ | grep pg_stat_statements

Y descubrí que el archivo sí existía, pero estaba en /usr/pgsql-17/lib/pg_stat_statements.so, mientras que PostgreSQL lo buscaba en $libdir/plugins/.

En pocas palabras: PostgreSQL estaba buscando en el lugar equivocado.


🛠️ La solución: Hacer que PostgreSQL encuentre lo que busca

✅ 1. Crear la carpeta de plugins y mover la librería

sudo mkdir -p /usr/pgsql-17/lib/plugins
sudo cp /usr/pgsql-17/lib/pg_stat_statements.so /usr/pgsql-17/lib/plugins/

Con esto, colocamos la librería donde PostgreSQL realmente la esperaba.


✅ 2. Asegurar que PostgreSQL la cargue en cada inicio

Abrí el archivo de configuración:

sudo nano /var/lib/pgsql/17/data/postgresql.conf

Verifiqué que la siguiente línea no estuviera comentada (sin # al inicio):

shared_preload_libraries = 'pg_stat_statements'

🔹 ¿Por qué esto es importante? Porque cualquier cambio en shared_preload_libraries requiere un reinicio de PostgreSQL para activarse.


✅ 3. Reiniciar PostgreSQL y verificar el estado

sudo systemctl restart postgresql-17
sudo systemctl status postgresql-17

Después de esto, ya no hubo errores al iniciar. 🎉


✅ 4. Crear la extensión dentro de PostgreSQL

Una vez PostgreSQL estaba funcionando sin errores, ejecuté:

sudo -u postgres psql -c "CREATE EXTENSION IF NOT EXISTS pg_stat_statements;"

¡Y funcionó sin errores! Ahora PostgreSQL registraba y analizaba todas las consultas.


📊 Consultas útiles para monitorear PostgreSQL

🔥 Listar las 10 consultas más lentas ejecutadas en la base de datos:

sudo -u postgres psql -c "SELECT query, calls, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;"

🧹 Resetear las estadísticas de pg_stat_statements:

sudo -u postgres psql -c "SELECT pg_stat_statements_reset();"

🔄 Asegurar que PostgreSQL siempre inicie con pg_stat_statements activo:

sudo systemctl enable postgresql-17

💡 Lo que aprendí en el proceso

1️⃣ No basta con instalar un módulo, hay que asegurarse de que PostgreSQL lo pueda cargar correctamente.

2️⃣ Los logs de PostgreSQL son tu mejor aliado. Revisarlos con journalctl ayuda a detectar problemas antes de que se conviertan en catástrofes.

3️⃣ Las rutas de librerías pueden ser un dolor de cabeza. Mover archivos a la ubicación correcta fue la clave para solucionar el problema.

4️⃣ pg_stat_statements es esencial para optimizar bases de datos. Ahora puedo detectar consultas lentas y mejorar el rendimiento sin hacer cambios a ciegas.

postgresql-problema-stat-statement


🚀 Conclusión

Después de un error crítico, logré estabilizar PostgreSQL y habilitar pg_stat_statements correctamente.

Ahora, el servidor monitorea el rendimiento de las consultas en tiempo real, lo que nos permite encontrar problemas antes de que afecten a los usuarios.

Este fue un recordatorio de que entender cómo PostgreSQL busca y carga sus librerías es tan importante como instalarlo bien.

Pequeños detalles como una ruta equivocada pueden romper todo.

📌 Ahora PostgreSQL está estable, optimizado y monitoreando las consultas en tiempo real.

Una gran victoria!! 🎯🔥

➡️ ¿Te ha pasado un error similar con PostgreSQL?

Cuéntamelo en los comentarios.

Si quieres conocer otros artículos parecidos a Rescatando PostgreSQL - Solución al Error con pg_stat_statements y Optimización del Monitoreo - Capítulo 16 puedes visitar la categoría Proyecto-IA.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Subir