2009/5/15 Luis D. García <[email protected]>: > Buenos días. > > Les escribo pues al implementar un esquema de replicación con Slony-I > obtuvimos un error del tipo "cache lookup failed for type 3044543". No sé > exactamente a qué se referirá este detalle, pero en vista de que el ambiente > sobre el cual se implementó se encontraba en producción, preferí optar por > detener el demonio 'slon' y eliminar el esquema de replicación. > > 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" > > 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 > 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 ....."... > En este sentido y de acuerdo a lo que pude ver en los threads, no creo que > el problema se deba tal cual a la implementación del Slony-I, lo que me > parece raro es que justamente sea con esas tablas que surja el fallo. > 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? > > Ahora, revisando los logs de PostgreSQL, el otro error que pude observar es > un fallo contínuo en el manejo de los archivos de transacción WAL, no sé si > esto tendrá algo que ver: > > 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? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- TIP 2: puedes desuscribirte de todas las listas simultáneamente (envía "unregister TuDirecciónDeCorreo" a [email protected])
