{"id":180,"date":"2009-03-31T15:54:52","date_gmt":"2009-03-31T18:54:52","guid":{"rendered":"http:\/\/www.maurom.com\/wp\/?p=180"},"modified":"2012-05-22T10:30:56","modified_gmt":"2012-05-22T13:30:56","slug":"postgfck","status":"publish","type":"post","link":"https:\/\/maurom.com\/blog\/2009\/03\/31\/postgfck\/","title":{"rendered":"Postgf*ck"},"content":{"rendered":"

Este marzo vino movido, de ah\u00ed la ausencia de posts en el blog, y abril pinta peor… El de hoy es breve y sencillo: un rant a PostgreSQL, o al sistema de archivos, o al LVM, o a la alineaci\u00f3n de los planetas.<\/p>\n

La cosa viene as\u00ed. Una aplicaci\u00f3n externa escrita en Java que est\u00e1 funcionando hace m\u00e1s de un a\u00f1o se queja y tira excepciones por doquier. Para quienes est\u00e1n acostumbrados a la verbosidad de las excepciones en Java, buscar la fuente del problema en 13651 l\u00edneas del log de excepciones para 73 errores, no es algo del otro mundo; en realidad todo se resum\u00eda a lo siguiente:<\/p>\n

org.postgresql.util.PSQLException: ERROR: fecha fuera de rango para\r\ntimestamp<\/pre>\n
\u00c9sa, estimado lector. \u00c9sa es la fuente del problema; lo dem\u00e1s era ch\u00e1chara adicional. As\u00ed que del log de excepciones pasamos al log del motor de base de datos, a ver que ten\u00eda para declarar.<\/p>\n
Efectivamente el error se repet\u00eda varias veces. Lo bueno es que postgres a\u00f1ade al mensaje de error la consulta SQL efectuada para que uno vaya viendo que es lo que sali\u00f3 mal. Lo malo, ahora, era la consulta. Nunca hab\u00eda visto en detalle las consultas que esa aplicaci\u00f3n le tiraba al servidor de base de datos, pues como ya viene compilado todo y lo \u00fanico que hay que hacer es ponerlo en el servidor de aplicaciones, ni me hab\u00eda molestado.<\/p>\n
Resulta que la consultita SQL es un select de 60 l\u00edneas de longitud, l\u00edneas completas de izquierda a derecha, una sucesi\u00f3n de caracteres que cubr\u00eda una pantalla completa y otra media. Quince SELECT unidos, algunos con subconsultas. Es la primera vez que veo semejante mont\u00f3n de uniones y subconsultas, fechas y comparaciones. De espanto, la verdad. De m\u00e1s est\u00e1 decir que si el sistema anda r\u00e1pido es todo gracias al planner de ejecuci\u00f3n del motor de base de datos.<\/p>\n
El paso siguiente fue hacer un volcado de la base de datos para mantener como resguardo, de forma tal de poder restaurar la base al estado original en caso de necesitar efectuar modificaciones. As\u00ed que con<\/p>\n
$ pg_dump -Ft -b appdb > appdb-snapshot.tar<\/pre>\n
nos qued\u00f3 un archivo de unos cincuentit\u00e1ntos megas listo para recuperar.<\/p>\n
La parte que sigue es una tarea detectivesca de descomponer la consulta para ver en cual de todas las fechas fallaba. Aqu\u00ed viene bien el algoritmo de b\u00fasqueda dicot\u00f3mica<\/a>: partimos la consulta al medio y ejecutamos la primera mitad en el servidor: si falla est\u00e1 all\u00ed, sino, en el resto de la consulta.<\/p>\n
Primera partici\u00f3n… Fall\u00f3… Bien, partimos la mitad que falla… Fall\u00f3 otra vez… y as\u00ed hasta dar con la comparaci\u00f3n:<\/p>\n
postgres=> SELECT codigo, detalle, vencimiento FROM elementos\r\nWHERE vencimiento <= '2009-03-30';<\/pre>\n
ERROR: fecha fuera de rango para timestamp<\/pre>\n
Humm… 2009-03-30 es una fecha v\u00e1lida, como as\u00ed tambi\u00e9n 2009-04-01, y sin embargo el error es el mismo. Ahora, con 2009-03-24 y previos anda perfecto, pero no con los posteriores. Se v\u00e9 que tiene un tema con el 24 de marzo, hasta ah\u00ed todo bien, pero de fechas siguientes ni hablar.<\/p>\n
Y m\u00e1s all\u00e1 de \u00e9se, no tira ning\u00fan otro error, eh. Extra\u00f1o por dem\u00e1s.<\/p>\n
\u00bfEstar\u00e1n los da\u00f1ados \u00edndices de la tabla? Luego de reconstruir los \u00edndices el error era el mismo. No, no est\u00e1n da\u00f1ados los \u00edndices.<\/p>\n
\u00bfSer\u00e1 la versi\u00f3n de PostgreSQL que tiene un bug? Restauramos el backup en dos equipos diferentes, uno con la misma versi\u00f3n y otro con una superior, y en ambos casos todo anduvo de maravillas. No, no es la versi\u00f3n de postgresql.<\/p>\n
Restauramos el backup en el servidor de producci\u00f3n y ah\u00ed lo tienen andando.
\n\u00bfMoraleja? todav\u00eda la estoy buscando…<\/p>\n","protected":false},"excerpt":{"rendered":"
Este marzo vino movido, de ah\u00ed la ausencia de posts en el blog, y abril pinta peor… El de hoy es breve y sencillo: un rant a PostgreSQL, o al sistema de archivos, o al LVM, o a la alineaci\u00f3n de los planetas. La cosa viene as\u00ed. Una aplicaci\u00f3n externa escrita en Java que est\u00e1 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[5,3,6],"_links":{"self":[{"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/posts\/180"}],"collection":[{"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/comments?post=180"}],"version-history":[{"count":0,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/posts\/180\/revisions"}],"wp:attachment":[{"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/media?parent=180"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/categories?post=180"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/tags?post=180"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}