Error en migración 3.22.1

SIU-Guaraní SIU-Guaraní - Técnicos
1

Buen día gente, al realizar el comando ./guarani migrar_base genera el siguiente error:

imagen

Entiendo que no puede generar el trigger ya que no existe la tabla.

Esto es correcto?

La siguiente consulta sería, al parar el script en este punto, quedo bien el schema de auditoría? Deberíamos hacer algo extra para que funcione de manera correcta?

Saludos

Ir a la issue.

2

Buen día Javier,
en este hilo habías planteado una situación similar, probá de seguir las indicaciones que se sugieren allí y comentanos si se pudo solucionar.

Saludos

3

@stalavera gracias por responder. El tema es que en este caso la tabla no existe, entonces no se si se borro de la versión o no entiendo porque no nos aparece.

Deberíamos tener esa tabla?

Según este hilo ya no se utiliza, o estoy confundido?

Saludos

4

Hola @jzeitune

La tabla mdp_actividad_economica_subsector se elimina en la versión 3.22.0 con el ticket #44396 en el diferencial BD/Diferenciales/3.22.0/001719.sql.

Lo extraño es porque la quiere volver a eliminar, ¿que te devuelve la siguiente query?

SELECT * FROM app_versiones_base WHERE ultimo_script_corrido ILIKE '%001719.sql';

Saludos.

5

Hola @lleonardis me devulve lo siguiente

image
image1083×115 8.31 KB

6

Si, el diferencial BD/Diferenciales/3.22.0/001719.sql parece que se ejecuto bien.

Observo lo siguiente:

  1. Función migrar_base_revisiones de php/extension_toba/guarani_modelo.php.

  2. Función get_tablas_triggers_desactivados de vendor/siu-toba/framework/php/modelo/lib/toba_auditoria_tablas_postgres.php.

  3. Función get_triggers_schema de vendor/siu-toba/framework/php/lib/db/toba_db_postgres7.php.

¿que te devuelve la siguiente query?

SELECT t.*,
					     c.relname as tabla,
				              n.nspname as schema
				FROM pg_trigger as t,
				            pg_class as c,
					   pg_namespace as n
				WHERE
					  t.tgrelid = c.oid
					  AND c.relnamespace = n.oid
					  AND n.nspname = 'negocio'
					  AND t.tgenabled = 'D'
					  AND t.tgname ILIKE 'tauditoria_%';

¿te lista mdp_actividad_economica_subsector en la columna tabla?

Saludos.

7

En caso de que la tabla mdp_actividad_economica_subsector siga estando en pg_class podes revisar esta respuesta que me dio el ChatGPT:

Si la tabla mdp_actividad_economica_subsector fue eliminada en PostgreSQL pero sigue apareciendo en la tabla de sistema pg_class, esto podría deberse a varias razones. Aquí tienes una explicación detallada de por qué sucede y cómo resolverlo:

1. Transacción pendiente o no confirmada

  • Si la eliminación de la tabla (DROP TABLE) se ejecutó dentro de una transacción que no fue confirmada (COMMIT) o fue revertida (ROLLBACK), la entrada en pg_class seguirá existiendo hasta que esa transacción finalice.

Cómo verificar:

SELECT * FROM pg_stat_activity WHERE state IN ('idle in transaction', 'active');

Solución:

  • Asegúrate de que la transacción que eliminó la tabla se haya confirmado:
    COMMIT;
  • Si es necesario, cancela la transacción:
    ROLLBACK;

2. Referencia fantasma debido a autovacuum pendiente

  • Cuando una tabla es eliminada, PostgreSQL marca la entrada en pg_class para ser limpiada por el proceso de autovacuum. Si el autovacuum no ha corrido o está retrasado, la entrada aún podría aparecer.

Cómo verificar:

  • Consulta el estado del autovacuum:
    SELECT * FROM pg_stat_all_tables WHERE relname = 'mdp_actividad_economica_subsector';

Solución:

  • Ejecuta un VACUUM FULL para limpiar las referencias pendientes:
    VACUUM FULL;

3. Dependencias en otras tablas o índices

  • Si otras tablas, índices, vistas o funciones dependían de mdp_actividad_economica_subsector, es posible que la eliminación de la tabla haya dejado referencias huérfanas en el sistema de catálogos.

Cómo verificar:

  • Busca dependencias:
    SELECT * 
FROM pg_depend d
JOIN pg_class c ON d.objid = c.oid
WHERE c.relname = 'mdp_actividad_economica_subsector';

Solución:

  • Asegúrate de que todas las dependencias relacionadas hayan sido eliminadas.

4. Problemas con extensiones o reglas

  • Algunas extensiones o configuraciones avanzadas pueden generar reglas o entradas personalizadas en pg_class, que persisten incluso después de eliminar la tabla.

Cómo verificar:

  • Revisa si la tabla está asociada con alguna extensión:
    SELECT * FROM pg_extension WHERE extname IN (SELECT relname FROM pg_class WHERE relname = 'mdp_actividad_economica_subsector');

Solución:

  • Si está vinculada a una extensión, considera reinstalar o revisar la extensión.

5. Corrupción en los catálogos del sistema

  • En casos raros, especialmente después de caídas abruptas o errores de disco, los catálogos del sistema pueden corromperse, dejando entradas inválidas.

Cómo verificar:

  • Busca inconsistencias en pg_class:
    SELECT relname, relkind, oid FROM pg_class WHERE relname = 'mdp_actividad_economica_subsector';

Solución:

  • Si confirmas que la tabla ya no debería existir, reconstruye los catálogos:
    pg_dump -Fc mydb > mydb.dump
dropdb mydb
createdb mydb
pg_restore -d mydb mydb.dump

6. Otras sesiones todavía usan la tabla

  • Si hay sesiones activas que están utilizando la tabla, PostgreSQL podría mantener la referencia en pg_class.

Cómo verificar:

  • Consulta las conexiones activas:
    SELECT * FROM pg_stat_activity WHERE query ILIKE '%mdp_actividad_economica_subsector%';

Solución:

  • Cancela las conexiones activas si es seguro hacerlo:
    SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE query ILIKE '%mdp_actividad_economica_subsector%';

Pasos recomendados:

  1. Confirma si la tabla aún existe:

    SELECT * FROM information_schema.tables WHERE table_name = 'mdp_actividad_economica_subsector';

  2. Verifica dependencias huérfanas:

    SELECT * 
FROM pg_depend 
WHERE objid = (SELECT oid FROM pg_class WHERE relname = 'mdp_actividad_economica_subsector');

  3. Fuerza la limpieza del catálogo:

    • Si confirmaste que no hay dependencias válidas:
      VACUUM FULL pg_class;

  4. Consulta el administrador del sistema si el problema persiste.