From: | Andrés P(dot)P(dot) <solopostgres(at)gmail(dot)com> |
---|---|
To: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Vacuum: pg_statistic_relid_att_index, duplicate key violates |
Date: | 2010-02-08 20:08:02 |
Message-ID: | 8a9759491002081208h189ccfaj6b9859e246323f39@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Hola!
Perdonen lo extenso..Creo tener la solución al siguiente problema pero lo
quiero validar con Uds. antes de aplicarlo.
Tengo una BD pequeña en la cual hay 4 tablas que tiene actividad cada 10
minutos que incluyen update y delete y en las cuales se ejecuta un vacuum en
cada uno de esos ciclos (10 minutos).... no ha sido necesario configurar un
autovacuum ya que el nivel de carga es bajo.
La BD en general funciona bien, sin embargo en esta actividad que se da cada
10 minutos existe la siguiente linea:
*vacuum full analyze bd_catalog.tab_tmp_carga; <-- esta tabla
se vacía y carga en cada ciclo...poca data..*
..su ejecución está enviando el siguiente error:
*ERROR: duplicate key violates unique constraint
"pg_statistic_relid_att_index"*
al truncar la tabla SÍ puedo realizar el vacuum sin problemas, pero en
cuanto ingresa data vuelve a aparecer el error al momento del vacuum..
También intenté borrar la tabla , pero me dio error:
*drop table bd_catalog.tab_tmp_carga;
ERROR: cache lookup failed for relation 41335
*
Al revisar el contenido de la tabla pg_statistic me encuentro con lo
siguiente:
*select starelid,staattnum, count(*) from pg_statistic group by
starelid,staattnum having count(*)>1;
starelid | staattnum | count
----------+-----------+-------
16918 | 1 | 2
16918 | 3 | 2
16927 | 2 | 2
16927 | 3 | 2
16927 | 4 | 2
*
Como decía, la carga es baja y la aplicación sigue funcionando "bien", sin
embargo me preocupa que no se esté realizando el vacuum porque a la larga
empezará a afectar el desempeño. Hace unos años atrás me pasó algo similar y
lo que hice fue recrear la BD, cargar un respaldo del momento con la data y
ejecutar los vacuum sobre los objetos necesarios y listo... fueron unos 10
minutos en todo el proceso y desde entonces no se habían presentado
problema. Sin embargo, ahora quiero aplicar una solución que sea más
correcta de acuerdo a lo que Uds. me confirmen o me indiquen.
Solución:
Googleando me encontré con la siguiente solución:
*delete from pg_statistic;
reindex table pg_statistic;
vacuum analyze;
*
... no he querido traerme un full backup para ver si se trae el error
consigo y probar la solución en desarrollo.
En fin..
Consultas:
Si hago lo que encontré en google estaría eliminando todas las
estadísticas... cierto??.. es posible solo borrar lo que necesite para la
tabla con el problema en particular??... cómo hago esa asociación?.... es
necesario el reindex en caso que el delete sea parcial??.. Finalmente, el
"vacuum analyze" lo podría reemplazar por el vacuum que uso sobre la tabla
del problema solamente.
Estoy claro que independiente de la solución... hay un problema en la
aplicación que está causando esta corrupción... pero eso lo dejaré para otra
futura consulta ya que trata sobre replicación...(pero insisto..es otro
cuento..).
Gracias desde ya.. y nuevamente, perdonen lo extenso.
Saludos
Andrés
From | Date | Subject | |
---|---|---|---|
Next Message | Alberto Rivera M. | 2010-02-08 20:15:13 | Re: Instalación postgresql-8.1 en Ubuntu 9.10 |
Previous Message | Jaime Giraldo | 2010-02-08 19:42:54 | Re: [pgsql-es-ayuda] Instalación postgresql-8.1 en Ubuntu 9.10 |