Re: PostgreSQL 8.1.0 catalog corruption - Mailing list pgsql-hackers

From Bob Ippolito
Subject Re: PostgreSQL 8.1.0 catalog corruption
Date
Msg-id 0B3996BA-ACDF-424B-88D1-4E4F5A922433@redivi.com
Whole thread Raw
In response to Re: PostgreSQL 8.1.0 catalog corruption  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PostgreSQL 8.1.0 catalog corruption  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Nov 21, 2005, at 3:56 PM, Tom Lane wrote:

> Bob Ippolito <bob@redivi.com> writes:
>> Sure, here it is:
>> http://undefined.org/mochi.pg_class-1.filedump.gz
>
> Well, I count at least a couple hundred deleted versions of that table
> row :-(.  What the heck were you doing with it?  As far as I can think
> offhand, only a schema modification would cause an update of the
> pg_class row.

There's an ETL process that does the following:

- Create a temp table
- COPY into the temp table
- do some transforms on the data
- create a dated table if it doesn't already exist
- fail miserably because the catalog is busted**

**: it normally does something else here, namely inserting a bunch of  
rows into the table

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!).

So what do I do now?  Kill the database, start over from a dump, and  
cross fingers that this doesn't pop up again?

-bob



pgsql-hackers by date:

Previous
From: Gregory Maxwell
Date:
Subject: Re: Improving count(*)
Next
From: Tom Lane
Date:
Subject: Re: PostgreSQL 8.1.0 catalog corruption