On Mon, Nov 08, 2021 at 10:45:50AM -0600, Carlos T. Groero Carmona wrote: > Hola lista, > [...] > > La tabla versions despues que termino el insert es de 510GB, es decir el > insert corrio por algun tiempo y no lo vimos terminar pues llevavamos mas > de 10 horas trabajando de madrugada y no sabiamos cuando terminaba. > > El problema es que ahora contamos el numeto de rows de la data que copiamos > y esta disminuyendo, 248 records menos en 3 minutos. > > Segimos teniendo la tabla old es decir no es un problema que perdimos la > informacion, y tenemos un backup tambien. > > El problema es que la data historica de los 7 meses se esta desvaneciendo > poco a poco sin haber nada que la elimine. > > Mi unica conjetura es que el insert fue interrumpido de alguna manera o el > proceso fue detenido y entonces la informacion copiada se esta como rolling > back, pero de una manera muy muy lenta. >
No, si el proceso hubiera sido interrumpido no habrías visto ningún registro nunca. Postgres no hace "rollback" por partes sino que hace commit o rollback de forma atómica, como es propio de una base que respecta la A de ACID. El problema real que puedes estar teniendo es que haya hecho un transaction wraparound. La solución consiste en ejecutar VACUUM, probablemente necesites ejecutar VACUUM de toda la base y de todas las bases (ejecutar el vacuumdb --all en la línea de comandos del sistema operativo puede ser una buena idea). Aunque me parece raro, si el problema fuera por eso debería estarse apagando o forzando un autovacuum con un mensaje que dice algo como "vacuum automático para prevenir wraparound". A menos que... estes usando una versión anterior a 9.6.20. -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de PostgreSQL
