Re: Vacuum: pg_statistic_relid_att_index, duplicate key violates

El 08/02/2010 21:08, Andrés P.P. escribió:
> 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
Te pregunto algo. ¿Si tienes pocos UPDATES/INSERT/DELETE por qué existe
la necesidad de ejecutar VACUUM ANALYZE cada 10 mins?
Realmente no veo por qué. VACUUM se usa frecuentemente cuando existen
muchas consultas DML, pero el tiempo que veo acá, es muy pequeño a mi
entender, y no hay necesidad de hacer eso en ese tiempo.
No recomiendo borrar el contenido de pg_statitic, ya que puede servirte
de mucho, además que ayuda al optimizador para la ejecución del plan de
las consultas; por lo que estarías trabajando sin estadísticas, por lo
que el optimizador pudiera no trabajar correctamente. No tengo mucho
conocimiento del tema, pero al menos es lo que creo.

Mi recomendación sería incrementar el tiempo de ejecución de VACUUM ANALYZE

Saludos

--
--------------------------------------------------------------------------------
"Para ser realmente grande, hay que estar con la gente, no por encima de ella."
Montesquieu
Ing. Marcos Luís Ortíz Valmaseda
PostgreSQL System DBA&& DWH -- BI Apprentice

Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)
Universidad de las Ciencias Informáticas

Linux User # 418229

-- PostgreSQL --
"TIP 4: No hagas 'kill -9' a postmaster"
http://www.postgresql-es.org
http://www.postgresql.org
http://www.planetpostgresql.org

-- DWH + BI --
The Data WareHousing Institute
http://www.tdwi.org
http://www.tdwi.org/cbip
---------------------------------------------------------------------------------