Re: PostgreSQL 8.1.0 catalog corruption

Tom Lane wrote:
> Bob Ippolito <bob@redivi.com> writes:
> > On Nov 21, 2005, at 3:56 PM, Tom Lane wrote:
> >> Well, I count at least a couple hundred deleted versions of that table
> >> row :-(.  What the heck were you doing with it?
> 
> > The ETL process keeps trying until it succeeds or someone stops it,  
> > so I guess that's why there's so much churn in there for that table.   
> > Kept trying to create it, and ran into the issue.  I'd estimate  
> > around 1700 to 1800 dead versions of that table, because it ran for  
> > some time before I noticed and stopped it... this is just a test box  
> > after all, I don't have 8.1 in production yet (thankfully!).
> 
> Um, no, that theory doesn't seem to explain the evidence.  A failed
> insertion would result in a row with an uncommitted XMIN and no XMAX.
> All of the entries I'm seeing have both XMIN and XMAX set.  A good-size
> fraction have the same XMIN and XMAX (but different CMIN and CMAX), but
> I see some that have different XMIN and XMAX.  It looks to me like the
> table was definitely created successfully, and it survived across
> multiple transactions ... but something was doing a lot of DDL changes
> on it.  If we could find out what, maybe we could reproduce the problem.

Maybe the UPDATE pg_class SET relhastriggers='f' that people is so fond
of doing to deactivate triggers?  Or something similar?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.