RE: configuración postgres 9 vs postgres 8 problema con checkpoints y autovacuum

Muchas gracias por tus respuestas, siempre bienvenidas y muy aclarativas.

>Lo segundo. Nota que wal_buffers se llevan a disco en cada commit
>sincrónico; y para commits asincrónicos, el proceso WAL writer los
>escribe y esto ocurre cada 200ms (wal_writer_delay si mal no recuerdo).

Si es wal_writer_delay.

saludos y muchas gracias.
________________________________________
From: Alvaro Herrera [alvherre(at)alvh(dot)no-ip(dot)org]
Sent: Monday, July 09, 2012 1:01 PM
To: Lazáro Rubén García Martínez
Cc: Jose Mercedes Venegas Acevedo; Ayuda
Subject: RE: [pgsql-es-ayuda] configuración postgres 9 vs postgres 8 problema con checkpoints y autovacuum

Excerpts from lgarciam's message of dom jul 08 15:53:42 -0400 2012:
> Alvaro muchas gracias por tus aclaraciones, simpre bienvenidas, sobre los checkpoints me quedan algunas dudas, y si puedes ayudarme a aclarar otras lagunas sería mucho mejor:
>
> 1. Cuando wal_buffers se llena también ocurre un checkpoint, o solamente ocurre durante checkpoint_segmentes o checkpoint_timeout?

Lo segundo. Nota que wal_buffers se llevan a disco en cada commit
sincrónico; y para commits asincrónicos, el proceso WAL writer los
escribe y esto ocurre cada 200ms (wal_writer_delay si mal no recuerdo).

> 2. Cuando se realiza una operación que afecta los datafiles, este cambio es almacenado en wal_buffers y en shared_buffers, pero solamente es sincronizado a disco cuando ocurre un checkpoint o durante wal_writer_delay que llevaría las páginas sucias del wal_buffers a los ficheros de wal y bgwriter_delay que llevaría las páginas sucias de shared_buffers a los datafiles de la db. Si esto es así, entonces durante un checkpoint, sería mucha la información que debería alterar los datafiles debido a la continua ejecución del proceso background writer?

No confundamos. Una cosa son los buffers de WAL, que se escriben a
segmentos de WAL cada cierto tanto. Esto lo hace cada proceso que hace
un commit sincrónico o bien el WAL writer.

Otra cosa totalmente aparte es un checkpoint, que se encarga de escribir
lo que hay en shared_buffers a los archivos de datos (datafiles que les
llamas tú). El checkpoint es ejecutado exclusivamente por el bgwriter.
Sí, son muchos los datos que escribir.

> 3. Tanto el proceso wal writer como background writer, después de ejecutados limpian las páginas sucias de wal_buffers y de shared_buffers que fueron sincronizadas?

Una página limpia es una página que no tiene cambios por ser escritos.
(No es lo mismo que una página desocupada). Por lo tanto,
cada página sucia es marcada "limpia" al escribirse.

> 4. Podría darse el caso de que después de ocurrir un checkpoint, tras una caida del servidor, cuando este inicie y trate de entrar en modo de recuperación, podria ser que la información que esté almacenada en los ficheros wal ya esté en la db producto de que el proceso de background writer fue ejecutado?

Claro. Es normal y esperable que pase esto.

> En caso de ser posible, que hace el gestor al respecto.

Nada. Se la salta.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
http://www.antiterroristas.cu
http://justiciaparaloscinco.wordpress.com

Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
http://www.antiterroristas.cu
http://justiciaparaloscinco.wordpress.com