Consulta vacuum

SIU-Wichi Técnicos Pentaho
1

Buenos días! Qué tal?

Al momento de actualizar datos (por ejemplo de Diaguita) en SIU-Wichi versión 7.2.0, con postgresql 14, me aparece el siguiente error (nuevo, hasta ahora nunca había sucedido en versiones anteriores):
2026/04/24 10:42:54 - INFO - Se copiaron correctamente las FT de DSA a DW
2026/04/24 10:42:54 - copiar_fts_dsa_dw - Starting entry [Copiadas las FT]
2026/04/24 10:42:54 - copiar_fts_dsa_dw - Finished job entry [Copiadas las FT] (result=[true])
2026/04/24 10:42:54 - copiar_fts_dsa_dw - Finished job entry [loguear fin] (result=[true])
2026/04/24 10:42:54 - copiar_fts_dsa_dw - Finished job entry [crear indices] (result=[true])
2026/04/24 10:42:54 - copiar_fts_dsa_dw - Finished job entry [actualizaciones_unidad_generica] (result=[true])
2026/04/24 10:42:54 - copiar_fts_dsa_dw - Finished job entry [ft_patrimonio] (result=[true])
2026/04/24 10:42:54 - copiar_fts_dsa_dw - Finished job entry [eliminar indices] (result=[true])
2026/04/24 10:42:54 - copiar_fts_dsa_dw - Finished job entry [loguear inicio] (result=[true])
2026/04/24 10:42:54 - principal_importacion_diaguita_dw - Starting entry [cerrar importación]
2026/04/24 10:42:54 - principal_importacion_diaguita_dw - Starting entry [setear conexion]
2026/04/24 10:42:54 - principal_importacion_diaguita_dw - Starting entry [vacuum]
2026/04/24 10:43:25 - vacuum - ERROR (version 9.4.0.0-343, build 0.0 from 2022-11-08 07.50.27 by buildguy) : An error occurred executing this job entry :
2026/04/24 10:43:25 - vacuum - Couldn’t execute SQL: vacuum analyze
2026/04/24 10:43:25 - vacuum -
2026/04/24 10:43:25 - vacuum - ERROR: no se pudo redimensionar el segmento de memoria compartida «/PostgreSQL.2851888630» a 67128608 bytes: No queda espacio en el dispositivo
2026/04/24 10:43:25 - principal_importacion_diaguita_dw - Finished job entry [vacuum] (result=[false])

El proceso de todas maneras finaliza y me deja actualizar los datos correctamente, pero entiendo que no puede realizar el proceso de limpieza vacuum posterior.
Analizando espacios de disco y memoria se ve que hay bastante disponible.
¿Hay algún parámetro de shared memory que se deba extender/cambiar en algún lado para que no suceda esto? ¿el problema puede ser por otra cosa? ¿o cuál sería la mejor solución?
Entiendo que existe un autovacuum que se ejecuta en determinados momentos, pero, ¿es necesario además ejecutar manualmente en la base otros procesos vacuum más profundos (del tipo analyze o full)?

Aguardo por comentarios, gracias.

2

Hola Matias,

Hay un parámetro relacionado con la memoria del PostgreSQL que es utilizada por el VACUUM, que es la memoria compartida.
En contenedores Docker, este valor definido por defecto (64MB) puede quedar corto. Para solucionarlo, se puede agregar la siguiente configuración en el docker-compose.yml, dentro del postgres:

shm_size: 256MB

Quedaría por ejemplo:
..
postgres:
image: postgres:14
container_name: postgres
restart: “unless-stopped”
shm_size: 256MB
…

Para que tome los cambios es necesario recrear el contenedor, atentos de que las bases de datos estén en un volumen, para no perder los datos que ya se cargaron:
docker compose up -d --force-recreate postgres

Para verificar si tomó el cambio, se puede ejecutar:
docker exec -it postgres df -h /dev/shm

Luego de un un proceso ETL se recomienda ejecutar un ANALYZE sobre las tablas afectadas (especialmente las más grandes).
El proceso automático de autovacuum es suficiente para el mantenimiento general.

3

Buenos días Eugenia.
Perfecto. Realicé la modificación sugerida y ahora finalizó sin errores. Muchas gracias!

Como dato por si a alguien más le sucede:
para que tome los cambios correctamente y levante la conexión de datos entre pentaho y postgres tuve que ejecutar al final un docker compose restart.

Saludos!