Re: checkpoints y disaster recovery anatomy

From: Richardson Hinestroza <richardhinestroza(at)gmail(dot)com>
To: Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, POSTGRES <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: checkpoints y disaster recovery anatomy
Date: 2015-10-13 12:32:48
Message-ID: CAMHqVuaY9YKH4VSOrWsx_TG5ye2H+z4WiM6CPNoUMjc2gQ13wA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Mil Gracias, efectivamente sus respuestas aclaran mis dudas. todo me queda
muy claro.

Att
Richard Hinestroza

2015-10-13 0:21 GMT-05:00 Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>:

> 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
>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Ruben Fitó 2015-10-13 13:55:19 Select con agregacion por períodos
Previous Message Jaime Casanova 2015-10-13 05:21:04 Re: checkpoints y disaster recovery anatomy