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.casan...@2ndquadrant.com>: > 2015-10-12 11:29 GMT-05:00 Alvaro Herrera <alvhe...@2ndquadrant.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 >
