Skip site navigation (1) Skip section navigation (2)

Re: strange behavior (corruption?) of large production

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: strange behavior (corruption?) of large production
Date: 2005-12-03 00:40:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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:

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:
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.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-12-03 00:43:24
Subject: Re: Optimizer oddness, possibly compounded in 8.1
Previous:From: Tom LaneDate: 2005-12-03 00:37:49
Subject: Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group