From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
Cc: | Richardson Hinestroza <richardhinestroza(at)gmail(dot)com>, POSTGRES <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: checkpoints y disaster recovery anatomy |
Date: | 2015-10-13 15:37:51 |
Message-ID: | 20151013153750.GR4405@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
From | Date | Subject | |
---|---|---|---|
Next Message | Richardson Hinestroza | 2015-10-13 17:18:41 | Re: checkpoints y disaster recovery anatomy |
Previous Message | Horacio Miranda | 2015-10-13 15:12:13 | Re: Re: [pgsql-es-ayuda] Select con agregacion por períodos |