Re: Cache lookup failed for type - Slony-I

Hola Jaime, gracias por tus respuestas.

El 16 de mayo de 2009 13:46, Jaime Casanova
<jcasanov(at)systemguards(dot)com(dot)ec>escribió:

> > postgres7 error: [-1: ERROR: cache lookup failed for type 3044543
> > CONTEXT: SQL statement "INSERT INTO _bd_cluster.sl_log_1 (log_origin,
> > log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) VALUES
> >
> > (1, $1, $2, nextval('_mic_cluster.sl_action_seq'), $3, $4);"] in
> > EXECUTE("UPDATE TGEN_SESSION SET FECHA_SALIDA = '2009-05-15 08:57:08',
> > ESTADO = 'INACTIVO' WHERE SESSION_ID = 'jm35et6hq0tceig413r0oevai0'")
> >
>
> Este error te esta saliendo en la pagina, verdad? (asumo porque te
> sale ese postgres7 que es del driver adodb de php), puedes ver que
> error arrojo al log de postgres? si es exactamente igual podrias
> tratar de aumentar la verbosidad del mensaje "log_error_verbosity =
> verbose"
>

Bueno en realidad sale tanto en la aplicación como en los logs de
PostgreSQL, siendo esto lógico ya que se debe a los triggers que genera el
Slony para la tabla consultada en ese momento.

> >
> > Cache lookup failed for function (hablan de que podría ser una
> interferencia
> > con tablas pg_*):
> > http://pgfoundry.org/pipermail/brasil-usuarios/20060927/002693.html
>
> slony 1.2 para abajo se metia con los catalogos del sistema para
> ciertas cosas... por que mejor no usas el 2.0, ese aprovecha ciertas
> caracteristicas de pg 8.3 para evitar meterse con los catalogos del
> sistema
>

Interesante, esto no lo sabía, sin embargo optamos por instalar la versión
que se encontraba en los repositorios, garantizando así que fuese una
versión estable. Recuerdo que en una oportunidad probé con 2.0 en un
ambiente virtualizado y recuerdo que obtuve errores con algo tipo "store
event" o algo similar.

>
> > Cache lookup failed for type (hay incluso una intervención de Jaime
> > indicando que es un BUG :s):
> > http://archives.postgresql.org/pgsql-admin/2005-12/msg00232.php
>
> en cierta medida el error del que hablo ahi se soluciono en 8.3 con el
> invalidador de cache, el problema es que mantenia en memoria los
> planes de ejecucion (incluidos oid de objetos como tablas, columnas y
> funciones que podrian ya no existir la segunda vez que ejecutabas la
> consulta)... un ejemplo comun es creando una tabla temporal dentro de
> una funcion eso te aseguraba un error del tipo "cache lookup failed
> for relation ....."...
>

Sinceramente pienso que por ahí viene el error, por eso mismo he dudado de
si ese detalle se haya solucionado por completo.

la verdad nunca habia visto ese error usando slony... seguro que ese
> error no te sale desde antes con otras tablas?
> no hiciste nada adicional ademas de configurar el slony? quiza nos
> puedas mostrar como lo configuraste?
>

Bueno en un principio yo pensé que se debía al Slony sobrecargando la BD,
pero cuando vi los otros threads, pude observar que también han surgido
errores similares con pgrouting, postgis y hasta con el mismo PostgreSQL
base, aunque no con el "lookup" sobre TYPE sino con FUNCTIONS y RELATIONS.

Por el IRC #postgresql estuve conversando con alguien y lo primero que me
preguntó fue si en algún momento había creado/dropeado/recreado el esquema
de replicación generado por el Slony, y de hecho así fue, ya que se hicieron
algunos cambios sobre la estructura de la BD y se quería generar toda la
replicación de nuevo desde cero. Al parecer al definir los esquemas y
levantar el Slony, se definen algunos "prepared queries", los cuales podrían
fallar debido a que surgirían cambios en los OIDs de las tablas a replicar o
algo similar.

Otra cosa que nos pareció extraño, es que la replicación del maestro al
esclavo se hizo a medias, es decir, teníamos casi 25Gb de información en el
nodo maestro y cerca de 16Gb en el esclavo al momento de presentarse los
fallos.

Después de discutir esto por un tiempo, opté por recrear el esquema de
replicación con un nuevo nombre para el Cluster, a ver si de esta manera se
evitaba el error, y de hecho hasta ahora así ha sido. Reconfiguré el Slony
con un nuevo CLUSTER NAME y recreé todo desde cero y hasta ahora no hemos
tenido problemas con ello.

> >
> > LOG: archive command failed with exit code 1
> > DETAIL: The failed archive command was: cp -i
> > pg_xlog/000000010000003200000050
> > /var/lib/pgsql/logs/wal/000000010000003200000050
> > WARNING: transaction log file "000000010000003200000050" could not be
> > archived: too many failures
> > LOG: unexpected EOF on client connection
> >
>
> no. esto es un intento de tener los WAL archivados pero el comando co
> no pudo mover el archivo... quiza falta de permisos en la carpeta wal?
>

Eso mismo estuve viendo luego, al parecer lo que sucedió es que en algún
punto el administrador del servidor optó por eliminar todos los logs
ubicados en pg_xlog y el archive_command de los WALs se quedó asociado a los
archivos anteriores, de hecho, resulta que desde hace ya algún tiempo los
WALs no se están moviendo a la carpeta indicada y están almacenándose
únicamente sobre pg_xlog.

Bueno hasta ahora tengo el mecanismo de replicación configurado con un nuevo
nombre y funcionando en producción, se han replicado 25Gb de 29Gb que son en
total y no ha surgido problema alguno.

Gracias por tu pronta respuesta Jaime.

Saludos.

--
Luis D. García M.

Telf: (+58) 2418662663
Cel.: (+58) 4123497674