Re: Vacuum: pg_statistic_relid_att_index, duplicate key violates

Marcos....

Lo de hacer el ciclo del vacuum cada 10 minutos es que estos Vacuum están en
un script que se ejecuta via crontab y están asociados a 2 tablas que se
vacían (truncate) completamente y luego se cargan con archivos que la
aplicación va dejando cada 10 minutos......... en ese sentido no sé si el
truncate cumple los mismos requisitos que un delete como para hacer
necesario o no el vacuum.... por esa razón se incluyó el vacuum después de
la carga justo en el momento anterior a que se ejecute una función que
calcula cosas con esa data.

Gracias por tu comentario.

Alvaro...

Es postgres 8.2.3....sip, es antigua pero hasta ahora ha tenido un desempeño
muy regular y satisfactorio... claramente hay que ver un tema en la
replicación a otro nodo que seria la causal de esta corrupción (es un cuento
largo... asi que lo dejo para después)..

La solución que planteas se parece a lo que encontré en google.... yo había
pensando en algo parcial....pero claro, talvez estoy mirando muy
livianamente la corrupción existente...sip, lo haré como tú dices....
después de limpiar la pg_statistics ejecuto el analyze sólo?.. qué
diferencia hay entre un "analyze" y un "vacuum analyze" para esta situación
particular (de puro curioso no más pregunto esto...).

Finalmente... No, no es la aplicación... me expresé mal.. es la solución que
se aplicó para la replicación que hay con otro Server..

Gracias Alvaro..

Saludos.

El 8 de febrero de 2010 17:23, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>escribió:

> > 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.
>
> ¿Qué versión de postgres es?
>
> > *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"*
>
> Hmm, esto no debería suceder. Lo que yo haría sería
>
> truncate pg_statistic;
> analyze;
>
>
> > 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??
>
> Si hay corrupción en la tabla lo mejor es partir de cero. No tienes
> cómo saber que el índice es válido a menos que lo reconstruyas
> totalmente.
>
> > Finalmente, el
> > "vacuum analyze" lo podría reemplazar por el vacuum que uso sobre la
> tabla
> > del problema solamente.
>
> Te recomiendo el truncate para vaciar completamente
> pg_statistic y luego un analyze para volver a llenarlo.
>
> > Estoy claro que independiente de la solución... hay un problema en la
> > aplicación que está causando esta corrupción...
>
> No, la aplicación no tiene ninguna manera de intervenir en la validez de
> pg_statistic. Yo más bien dudaría de algún bug en Postgres, en el
> kernel, o bien problemas de hardware.
>
>
> --
> Alvaro Herrera Vendo parcela en Valdivia: http://rie.cl/?a=255568
> "Es filósofo el que disfruta con los enigmas" (G. Coli)
>