Re: Decodificar WAL para obtener DML.

Alvaro,
Entiendo, muchas gracias por la información.
Efectivamente había comenzado intentando hacer algo con pg_xlogdump en
función de lo que vi en la web, pero no lograba lo que quería (justamente
los comandos en formato lógico).
Me pareció raro que no hubiera alguna salida.

En cuanto al comentario de Jaime, yo también entendí que hablaba de
log_statement=dml (de hecho mi pregunta se refería a eso).
Si efectivamente solo requiere de espacio no parece una mala alternativa,
al menos para cubrirse durante algunos momentos críticos.

Saludos y gracias a todos nuevamente.
Federico.

El 23 de abril de 2018, 14:23, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
escribió:

> Federico Pascual escribió:
>
> > Si tendría el físico (de bastante antes) más el archivado hasta el punto
> > inmediatamente anterior.
> >
> > Es una situación hipotética, afortunadamente no pasó. Pero en la
> > dependencia donde trabajo, si sucedió algo similar sobre una db en MySQL
> y
> > fue posible la recuperación decodificando los bin log con una herramienta
> > específica que trae el motor para ese fin.
>
> Una herramienta útil es un respaldo físico (base backup) más los
> WAL archivados. Puedes usar un "restore point" (una marca en el WAL que
> dice "aquí voy a empezar a hacer XYZ"), que puedes usar para indicarle
> al sistema "recupéreme justo hasta aquí".
>
> No existe una manera de tomar un registro WAL y mostrarte una
> representación lógica, del tipo "insert into xyz values (1,2,3)". No es
> que sea imposible, pero sería muy trabajoso hacerlo y que sepamos nadie
> lo ha hecho.
>
> Suponemos que ya conoces pg_waldump (antes conocido como pg_xlogdump).
> No entrega registros "legibles", pero podrías modificarlo para que te
> entregara secuencias de bytes. Esto último no es muy útil.
>
> Existe un módulo llamado pg_dirtyread que tampoco sirve para tus
> propósitos.
>
> > Hay otro problema relacionado y es que para implementar PITR siempre
> > implica trabajar con TODO el motor (no sobre una DB en particular) y se
> > hace poco práctico cuando hay muchas DBs en el mismo server y el problema
> > es solo con una.
>
> Cierto.
>
> > En cuanto al log de los dml tonces solo tendría implicaciones de
> ocupación
> > de espacio?
>
> En este tema, nos parece que Jaime se refiere al log de
> log_statement=dml, no al WAL.
>
>
> Otra alternativa es un sistema tipo auditoría, pero tienen un sobrecosto
> de rendimiento no menor.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>