Hola Lista
Pero tengo entendido que ejecutar un pg_resetxlog es el ultimo recurso y una vez suba la instancia hay realizar un dump/initdb/restore https://www.postgresql.org/docs/9.4/static/app-pgresetxlog.html "After running this command, it should be possible to start the server, but bear in mind that the database might contain inconsistent data due to partially-committed transactions. You should immediately dump your data, run initdb, and reload. After reload, check for inconsistencies and repair as needed." El 12 de julio de 2016, 07:27, Hellmuth Vargas<hiv...@gmail.com> escribió: > Hola Lista > > > Pero tengo e tendido > > > After running this command, it should be possible to start the server, but > bear in mind that the database might contain inconsistent data due to > partially-committed transactions. You should immediately dump your data, run > initdb, and reload. After reload, check for inconsistencies and repair as > needed. > > El 11 de julio de 2016, 21:43, Alvaro Herrera<alvhe...@2ndquadrant.com> > escribió: > >> Jaime Casanova escribió: >> > 2016-07-08 5:04 GMT-05:00 Francisco Olarte <fola...@peoplecall.com>: >> > > Eduardo: >> > > >> > > 2016-07-07 19:40 GMT+02:00 Eduardo Morras <emorr...@yahoo.es>: >> > > ... >> > >>> Es mas, haz una prueba pero me da que el maestro, salvo que hagas >> > >>> algun truco para guardar el xlog, se pudriria no solo cuando se >> > >>> ahostie, sino tambien cuando pares la maquina ( la prueba es facil, >> > >>> coge un cluster, paralo, borra el directorio de xlog, arranca a ver >> > >>> que pasa ), en cuyo caso vas a tener mas movidas aun con los >> upgrades. >> > >> Ahi depende de como pares la maquina. Siempre parar primero Postgres >> > >> (pg_ctl stop -m smart) y despues hacer el shutdown. Nunca confio en >> que >> > >> llamar a shutdown directamente pueda parar correctamente postgres o >> > >> cualquier otro demonio mio, tiene la mala costumbre de matar todo >> > >> pasado un timeout y dejar las cosas a medio hacer. >> > > >> > > No, no es eso lo que digo. Lo que digo es que en condiciones normales >> > > si tu haces un reboot, y tienes la maquina bien configurada, el >> > > postgres tiene el xlog ahi cuando rearranca, que no se lo que se queda >> > > dentro. La cosa es si puede hacer un pgctl stop smart, borrar el >> > > directorio de xlog, pgctl start y sigue funcionando. >> > >> > no, no puedes. >> > al arrancar postgres necesita ver no solo el directorio pg_xlog, >> > tambien necesita ver segmentos del WAL (lo que va dentro del >> > directorio) de al menos 2 chekpoints para atras... >> >> Sólo un checkpoint para atrás (el anterior se usa sólo si por alguna >> razón no puede leer el último) ... y en un "smart shutdown" (y también >> en un fast shutdown) el sistema escribe un checkpoint de apagado al >> terminar, así que en realidad no necesitaría leer nada. Pero el sistema >> no tiene cómo saber que no hay nada después del checkpoint de apagado, >> sin leer el último segmento de WAL. >> >> Supongo que podría hacer un pg_resetxlog antes de partir. >> >> -- >> Álvaro Herrera http://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> >> - >> Enviado a la lista de correo pgsql-es-ayuda ( >> pgsql-es-ayuda@postgresql.org) >> Para cambiar tu suscripción: >> http://www.postgresql.org/mailpref/pgsql-es-ayuda >> > > > > -- > Cordialmente, > > Ing. Hellmuth I. Vargas S. > Esp. Telemática y Negocios por Internet > Oracle Database 10g Administrator Certified Associate > EnterpriseDB Certified PostgreSQL 9.3 Associate > > -- Cordialmente, Ing. Hellmuth I. Vargas S. Esp. Telemática y Negocios por Internet Oracle Database 10g Administrator Certified Associate EnterpriseDB Certified PostgreSQL 9.3 Associate
