> On 16/02/2019, at 4:07 AM, Carlos T. Groero Carmona <cton...@gmail.com> wrote: > > Gracias a todos por sus comentarios y ayudarme a pasar a traves de esta > situacion tan rara y peligrosa... > > @Horacio Miranda <mailto:hmira...@gmail.com>, voy a empezar a trabajar en > esto lo mas rapido posible, mi template0 esta el 78%.. > Solo una pregunta, haciendo vacuum FULL freze a template0 or template1 or > postgres hay alguna posibilidad que mi base de datos en producion tenga > alguna consecuencia?, pregunto esto porque estariamos bloqueando todas las > tablas en esas base de datos.
Sin tener un ambiente/problema similar y sin probarlo no te puedo decir que no la va a tener, vas a tener que probar en tu ambiente de pruebas y cruzar los dedos para que producción se comporte de forma similar. Solo atento a los bloqueos y dado el tamaño de la base o nivel de transacciones es mejor hacer esto en un periodo de baja carga, toma el tiempo que toma para sacar una métrica. Saludos y suerte, este tema se ve interesante, primera vez que me toca ver algo como esto. > Saludos, > Carlos > > > On Fri, Feb 15, 2019 at 3:19 AM Horacio Miranda <hmira...@gmail.com > <mailto:hmira...@gmail.com>> wrote: > Hola despues de jugar un buen rato, creo que es necesario abrir y cerrar > el template0 para poder bajar la marca de los datfrozenxid en bases de > datos de alta transaccion. > > mis sistemas que tengo en postgres funcionando desde el 2010 sin > problemas algunos no tenian ni siquiera un 1% usado. > > No me ha tocado mirar bases de datos con tanta carga como para tener > este problema y me imagino que los desarrolladores tanpoco ven la > necesidad que vacuumdb haga el trabajo en el template0, sin embargo creo > que es posible agregar esta funcionalidad de have vacuumdb en el > template0 sin tener que brirla ( pensando en voz alta ), este el primer > caso que veo. > > @Carlos, por favor abre la base template0 ( hace el vacuumdb -F -a > template1 ) y luego vuelve a cerrar el template0. > > Desde el template1 puedes hacer esto si quieres > > update pg_database set datallowconn='t' where datname = 'template0'; > > \c template0 > > vacuum full freeze ; > > update pg_database set datallowconn='f' where datname = 'template0'; > > Dejar esto en algun script. > > On 15/02/2019 12:08 PM, Alvaro Herrera wrote: > > Carlos T. Groero Carmona escribió: > >> Dejenme aclarar algo porque quizas no me he hecho entender, yo no escribo > >> en template0 or en template1, yo tengo 9 base de datos en el cluster el 98% > >> de las transactiones las hago en db_prod y el resto en 3 pequenas base de > >> datos. > >> > >> El problema es que el XID de todas las base de datos crecen por igual, en > >> las ultimas 24H el XID crecio en 42,039,358, crecio por igual para las 9 > >> base de datos en el cluster, incluyendo, template0, template1 y postgres. > >> Miren les muestro el analysis que he estado haciendo: > >> Database 11-Feb 12-Feb 13-Feb 14-Feb 15-Feb 16-Feb 17-Feb > >> DB_1 194,502,390 234,727,250 282,500,743 324,540,101 > >> DB_2 194,307,274 234,532,134 282,305,627 324,344,985 > > Eh ... ¿de dónde vienen esos números? Si es un age(datfrozenxid), es > > natural que crezcan todos por igual, porque la función age(xid) resta el > > valor del XID actual (que es global para todas las DBs) el valor del > > datfrozenxid de cada DB. > >
