noisia: generador de cargas de trabajo dañinas para PostgreSQL

• Herramienta de inyección de fallas que crea intencionalmente situaciones de error como agotamiento de conexiones/esperas por bloqueos/interbloqueos/OOM/falta de disco para hacer pruebas
• Admite diversas cargas de trabajo, desde transacciones inactivas/rollbacks/interbloqueos/archivos temporales/terminación de backends hasta crecimiento explosivo de WAL/hinchazón de tablas
• Algunas cargas de trabajo pueden ir más allá de agotar max_connections, causar retrasos de replicación o degradar el rendimiento del almacenamiento, y provocar un PANIC o reinicio completo de la instancia de PostgreSQL
• Puede ejecutarse directamente como imagen Docker o importar cargas de trabajo individuales desde código Go; es obligatorio usar context y tiempos límite para evitar ejecuciones infinitas
• Cargas de trabajo compatibles
  • idle transactions: deja transacciones abiertas sin hacer nada, lo que interfiere con la limpieza (VACUUM) e infla tablas/índices
  • rollbacks: envía consultas incorrectas a propósito para generar errores y aumentar la cantidad de rollbacks
  • waiting transactions: una sesión bloquea una tabla y las conexiones posteriores quedan esperando en fila hasta alcanzar el límite de conexiones (max_connections), impidiendo nuevas conexiones
  • deadlocks: pone dos transacciones en un interbloqueo en el que cada una espera el lock de la otra
  • temporary files: ordena datos más grandes que la memoria (work_mem) para hacer que se vuelquen archivos temporales en disco (desaparece si se aumenta work_mem)
  • terminate backends: termina forzosamente de forma aleatoria sesiones/consultas en ejecución mediante pg_terminate_backend() y similares
  • failed connections: acapara todas las conexiones para que otros clientes no puedan conectarse en absoluto. Agota el límite de max_connections
  • fork connections: envía consultas cortas usando una conexión nueva cada vez, haciendo que Postgres cree demasiados procesos hijo
  • backend-killer: una sesión acumula continuamente prepared statements para inflar la memoria y hacer que un OOM-kill reinicie toda la instancia
  • slot-bloat: un replication slot que nadie lee retiene el WAL hasta llenar pg_wal y el disco, provocando un PANIC de la instancia
  • wal-flood: dispara el WAL con workers UPDATE en paralelo para generar retrasos de replicación/presión de IO (una versión “visible” de slot-bloat; que se llene el disco depende del entorno)
  • bloat-churn: infla la tabla con UPDATE en paralelo más rápido que autovacuum, pero después de detenerlo se puede revertir con VACUUM FULL/pg_repack/REINDEX CONCURRENTLY
• No ejecutarlo sin entenderlo por completo; debe usarse solo con fines de prueba
• Licencia BSD-3-Clause