From: | Richardson Hinestroza <richardhinestroza(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, POSTGRES <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: checkpoints y disaster recovery anatomy |
Date: | 2015-10-13 17:18:41 |
Message-ID: | CAMHqVuYPQC2w4qqX=HbuRY_m4fMDET2NvNh4MJkMT6XTwiRV9Q@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Cordial saludo, finalmente después de leer las respuestas quisiera saber en
que momento se escribe en el WAL el
Checkpoint log Record; si se escribe al comenzar el checkpoint o al
finalizar el checkpoint. esto lo pregunto porque que la "distancia" entre
los puntos de inicio y fin del checkpoint puede ser grande si consideramos
el parametro "checkpoint_completion_target".
2015-10-13 10:37 GMT-05:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
> Jaime Casanova escribió:
> > 2015-10-12 11:29 GMT-05:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
>
> > > No se bloquean transacciones. Lo que se hace es que se hace un primer
> > > recorrido sobre todos los buffers, marcando todos los que están DIRTY
> > > con un flag CHECKPOINT_NEEDED (sin escribir nada a disco); luego se
> > > empieza la escritura a disco haciendo un segundo recorrido que escribe
> a
> > > disco todos los buffers que tienen ese flag.
> >
> > De hecho CreateCheckPoint() dice que si bloqueamos transacciones o al
> > menos llamamos a WALInsertLockAcquireExclusive(), que según entiendo
> > evitará que se escriba nuevo WAL (lo que en esencia bloquea las
> > operaciones/transacciones de escritura).
> > Aunque es periodo de tiempo muy corto, parece que solo el necesario
> > para calcular el próximo punto de redo para que a partir de ahí se
> inserten
> > los siguientes registros del WAL.
>
> No es lo mismo --- eso bloquea sólo el "período crítico de commit" de la
> transacción, que como tú dices es muy corto.
>
> > > Si un segundo proceso modifica el buffer después del primer recorrido,
> > > no se hace nada especial: la versión que se escriba en disco será la
> > > versión modificada.
> >
> > según entiendo del comentario en BufferSync(), este segundo proceso,
> > al ver el flag BM_CHECKPOINT_NEEDED, de hecho se encargaría de escribir
> > el buffer a disco y sacarlo de shared_buffers, estoy en lo correcto?
> > """
> > * Whenever a page with BM_CHECKPOINT_NEEDED is written out,
> > either by us
> > * later in this function, or by normal backends or the
> > bgwriter cleaning
> > * scan, the flag is cleared. Any buffer dirtied after this
> point won't
> > * have the flag set.
> > """
>
> Esto significa que todos los buffers con BM_CHECKPOINT_NEEDED tienen que
> ser escritos, "ya sea por nosotros mismos" (es decir el proceso
> checkpointer) o bien "por cualquier otro backend", o bien por el
> bgwriter, y que la bandera se limpia una vez que la escritura ocurre.
> El que salga o no de shared buffers (evict) va a depender de si lo
> escribe el checkpointer o bgwriter (se queda en shared buffers) o lo
> escribe un backend (sale de s.b., porque lo que el backend necesita es
> el buffer para poder leer otra página). Finalmente, indica que
> cualquier buffer que sea "dirtied" a partir de ese momento no va a tener
> la bandera BM_CHECKPOINT_NEEDED y por lo tanto no necesitará escribirse
> para completar el checkpoint.
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-10-13 17:23:07 | Re: checkpoints y disaster recovery anatomy |
Previous Message | Alvaro Herrera | 2015-10-13 15:37:51 | Re: checkpoints y disaster recovery anatomy |