Re: checkpoints y disaster recovery anatomy

From: Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(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 05:21:04
Message-ID: CAJGNTeMwUDdrAO43_ObUUAL=dwD8-7e0e-tUfz0f6E9o+YgJ1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

2015-10-12 11:29 GMT-05:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
> Richardson Hinestroza escribió:
>
> Hola,
>
>> He estado leyendo en la documentacion como funcionan los checkpoints en
>> Postgresql, pero quisiera saber que pasa si durante un checkpoint una
>> transaccion necesita hacer cambios a una de las dirty pages que estan en la
>> lista seleccionada por el checkpoint para ser escritas en disco.
>>
>> No he podido entender si Posgresql bloquea transacciones que necesitan
>> hacer cambios a las dirty page seleccionadas por un checkpoint para ser
>> escritas a disco (por ejemplo INFORMIX bloquea estas transacciones).
>
> 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.

>> Si Postgresql no bloquea estas transacciones entonces que version de
>> pagina se guarda en disco? la version que estaba cuando comenzo el
>> checkpoint o la version modificada por la transaccion durante el
>> checkpoint. Ademas, cual seria la version de la data en disco, seria
>> la version correspondiente al instante de tiempo cuando se inicio el
>> checkpoint o cuando este termino?.
>
> 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.
"""
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Richardson Hinestroza 2015-10-13 12:32:48 Re: checkpoints y disaster recovery anatomy
Previous Message Alvaro Herrera 2015-10-12 16:29:31 Re: checkpoints y disaster recovery anatomy