Re: Monitoreo gráfico de postgresql

On Sat, Aug 13, 2005 at 02:00:04AM -0300, Dario wrote:

> Oracle (según se) no puede volver el tiempo atr}as y desconfirmar
> transacciones comprometidas (comiteadas), hay que hacer un restore y aplicar
> archived logs.

Aja, esto es exactamente igual que en Postgres. Interesante!

> Se refiere a UNDO como el hecho deshacer cambios en los datafiles
> cuando se ejecuta un rollback.

Aca aparece la diferencia: Postgres no hace UNDO para el rollback,
porque el MVCC se maneja de manera diferente. Postgres deja la version
antigua y la nueva de la tupla en el "heap" de la tabla (el archivo
donde estan los datos); por lo tanto para hacer rollback, basta con
marcar en alguna parte "esta transaccion hizo rollback", y cuando se
examinan ambas versiones de las tuplas hay que ver si la transaccion
hizo rollback o commit. Para limpiar el heap de las versiones viejas se
hace VACUUM.

En cambio Oracle guarda una sola version de la tupla en el heap de la
tabla, las otras versiones se guardan en un "rollback segment". Por lo
tanto nunca se necesita VACUUM, pero la desventaja es que la transaccion
que esta modificando los datos tiene que escribir en el rollback
segment, ademas de escribir en el heap.

El compromiso entre usar un "overwriting storage manager" (como hace
Oracle) versus un "non-overwriting storage manager" (como Postgres) es
ese: quien tiene la responsabilidad de limpiar la tabla, si la misma
transaccion que la modifica, o bien se deja para despues. La decision
que se usa en Postgres (el non-overwriting) significa que la transaccion
misma puede tener mejor rendimiento porque tiene menos trabajo; y
ademas, un rollback es muy barato porque no hay que hacer UNDO. La
desventaja es tener que ejecutar VACUUM de vez en cuando.

> "REDO" es parte del recovery de transacciones ante la caida del servidor. Se
> hace redo de todas las sentencias no escritas en los datafiles
> (independientemente de si forman parte de una transacción comprometida o no)
> hasta que se lee todo el log, luego hace un undo de las sentencias que
> forman parte de una transacción que no se cerró.

En Postgres se hace todo el REDO y listo. No es necesario hacer el
UNDO, por las mismas razones de arriba.

> Lo que se podría hacer ver como una vuelta atras, es la flashback query.
> Sería algo así como poder decirle al motor que no me lea la última versión
> ya comiteada de un registro, sino que use una tupla anterior (las que
> después limpia el vacuum) aun siendo esta query parte de una transacción
> posterior. Es una manera de recuperar datos (delete * from table --
> where...; commit; auch) o de acceder información (select valor from
> cotizaciones AS OF TIMESTAMP (systimestamp - interval 1 day)) sin tener que
> crear una tabla de históricos... puede consumir mucho disco, pero el espacio
> en disco es más barato que las horas/hombre.

En el POSTGRES que salio de Berkeley existia esta caracteristica. Se
llamaba "time travel". Una de las primeras cosas que se hicieron en
PostgreSQL fue eliminarla, porque traia varios problemas complicados.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)