Re: strange behavior (corruption?) of large production - Mailing list pgsql-hackers

From Joe Conway
Subject Re: strange behavior (corruption?) of large production
Date
Msg-id 4390E98F.6010508@joeconway.com
Whole thread Raw
In response to Re: strange behavior (corruption?) of large production database  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: strange behavior (corruption?) of large production database  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>>Since this is a production machine, putting pg_filedump on it may be 
>>problematic -- if I grovel through the bits by hand, can you give me a 
>>hint about what to look for?
> 
> How about you copy off the pg_database file to someplace where it's OK
> to run pg_filedump?  Doing that by hand is mighty tedious.
> 
> BTW, forget the "FREEZE" part, just VACUUM:
> http://archives.postgresql.org/pgsql-general/2005-11/msg00097.php
> 

That was it, apparently.

I tarred up the global directory so I can do posthoc analysis, but they 
were too anxious to wait any longer, so we ran vacuum on pg_database and 
pg_shadow and now everything appears normal again. I pointed them to:
http://www.postgresql.org/docs/7.4/interactive/maintenance.html
and advised that they read it carefully.

Since this database has many large, but static tables (i.e. new data is 
loaded each day, but the tables are partitioned into year-month tables), 
I'm thinking we can run VACUUM FREEZE on the whole database once, and 
then run VACUUM FREEZE periodically on just the tables that have had 
rows added since the last time -- is that correct?

Thanks again for the quick help.

Joe




pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: Optimizer oddness, possibly compounded in 8.1
Next
From: Tom Lane
Date:
Subject: Re: Optimizer oddness, possibly compounded in 8.1