Re: Vacuum: pg_statistic_relid_att_index, duplicate key violates

Jaime

El autovacuum está en off desde un principio.........la carga es tan pequeña
y "específica", por decirlo de alguna forma, que se decidió que se hicieran
vacuums en estas cargas que se daban cada 10 minutos ya que era el momento
en el que se limpiaban dos tablas y se generaban updates en
otras..... tenemos otras plataformas en las que el autovacuum sí está
habilitado y realiza su trabajo perfectamente..........pero en esta
aplicación por sus particularidades se decidió que el vacuum fuera
controlado.... es sólo eso.

Cuándo dices "catalogos del sistema" te refieres a los particulares que usa
la aplicación??....o a aquellos que son de tipo administrativo del motor
postgres?.... En los de la aplicación sólo existen esos vacuums que he
mencionado.... a los administrativos (pg_catalog..u otros..no sé).. no!, a
esos no les he hecho vacuums...

Lo de la corrupción, no se preocupen... no tiene que ver con el motor, la
versión o el uso del autovacuum.... como lo dije en correos previos la
corrupción se debe a la forma como se está haciendo una "replicación" a otro
nodo que está pasivo..... El motivo inicial de este correo era solamente
solucionar lo inmediato que era arreglar el error que devolvía el vacuum
sobre una tabla específica (Seguía funcionando bien la aplicación... pero me
interesaba eliminar ese error porque a la larga seguramente me iba a afectar
en el desempeño..)...... lo del modelo de replicación y causa de la
corrupción es más extenso y lo veré después...y seguramente les volveré a
consultar...

Gracias a todos los que hicieron sus aportes. Lo bueno de esta lista (y no
soy listero frecuente) es que vas por A... y vuelves con A, B y C...

Saludos
AP.

El 9 de febrero de 2010 00:45, Jaime Casanova
<jcasanov(at)systemguards(dot)com(dot)ec>escribió:

> 2010/2/8 Andrés P.P. <solopostgres(at)gmail(dot)com>:
> >
> > 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.
> >
>
> esto quiere decir que apagaste el auto vacuum o que no lo has
> configurado mas alla del predeterminado?
>
> si lo que hiciste fue apagar autovacuum (autovacuum = off en el
> postgresql.conf) deberias estar haciendo un vacuum de los catalogos
> del sistema cada cierto tiempo... lo estas haciendo?
>
> No estoy seguro si eso podria causar el tipo de corrupcion que
> mencionas pero si podria traer problemas... ahora, si como menciona
> Alvaro es un bug habria que saber si esta solucionado ya o no...
> dices que usas 8.2.3 y veo que en:
>
> 8.2.4 se arreglo esto:
> Fix potential-data-corruption bug in how VACUUM FULL handles UPDATE
> chains (Tom, Pavan Deolasee)
>
> y en 8.2.5:
> Prevent index corruption when a transaction inserts rows and then
> aborts close to the end of a concurrent VACUUM on the same table (Tom)
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Asesoría y desarrollo de sistemas
> Guayaquil - Ecuador
> Cel. +59387171157
>