PostgreSQL I

Espero que el trabajo me siga enseñando todos los días algo nuevo (es casi lo único bueno de trabajar :-/). El día de hoy fue bastante complicado, a la mañana la base empezó a tirar excepciones horrendas. Bue, otra vez más los índices… a regenerarlos. PUM.

 ERROR:  could not access status of transaction 4294967295
DETAIL: could not open file "pg_clog/0C4F": Archivo o directorio no encontrado


Parece que postgres guarda en esa carpeta (pg_clog) las transacciones que no fueron commiteadas, por algún motivo (sospechamos que falta de espacio en el server :S). Con lo que terminó buscando qué pasaba con cierta transacción (en nuestro caso la 4294967295) ahí y no había nada, directamente no existía el archivo. Recorrimos un poco internet y encontramos que un workaround era generar ese archivo lleno de 0 con un tamaño de 256k con el siguiente comando:

dd bs=256k count=1 < /dev/zero gt; $PGDATA/pg_clog/0CF4

continuamos pero ahora nos tiró error en otro archivo con otra transacción, repetimos el comando ajustándolo para el nuevo archivo y lo mismo, el mismo error, otra transacción y archivo.

Entre idas y vueltas, dumps y nerviosismo (presidido por Andrés, aunque en la práctica me vieron más histérica a mí) nos dimos cuenta que el problema al hacer cualquier cosa con la tabla pg_largeobject. Luego de hacer todo tipo de backups con todas las técnicas que el pg_dump nos permitía (muchas salieron mal por ya el problema de inconsistencia de la base (incluso copiamos los binarios propios de postgres a otro lado, estábamos como locos) empezamos a tirar fruta.

Fran hizo un script en php que generó todas las combinaciones de 0000 a 0FFF y corría el script de antes las 4000 veces (no era mucho, era 1GB de datos), y Mata acotó, una vez que el script estaba listo y corriendo, por qué no habíamos hecho 400 link simbólicos al mismo archivo… y si, por eso son la raza más productiva del planeta. Una vez hecho esto pudimos reindexar la base, pero todo quedó en un estado bastante cacónico. Supuestamente ahora, pg_largeobject tenía claves repetidas que la volvían inconsistente. Leyendo, otra vez Mata, nos alertó que esa tabla es una tabla interna que usa postgres para guardar los BLOB. Si crean una tabla con una ‘columna’ BLOB (en realidad no se si esto es así si lo hacés a mano, supongo que sí, pero en nuestro caso lo hizo hibernate esto, así que no se a ciencia cierta qué tipo de CREATE TABLE hizo) esta va a tener nombre OID que es un ID que apunta al BLOB en sí guardado en la tabla en cuestión (Jime notó que los guardaba ahí dentro, incluso, paginados). Así que lo que hicimos, como eran pocos los BLOB guardados y fácilmente recuperables, pusimos todas las columnas ODI en null, borramos totalmente esa tabla, reindexamos, corrimos un script que hacía el insert de las imágenes en la base (esto ya lo teníamos de hace mucho, lo hizo Hernán, que fue al único que no nombré porque se había quedado flojo en la casa, y cuando digo flojo, es flojo-flojo). Y listo :D. Salió andando nuevamente :D

pd= me cansé del xhtml :), me canso rápido de las cosas, este post ya rompe con varios estándares

Advertisements

There are no comments on this post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s