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 Lane||Date: 2005-12-03 00:43:24|
|Subject: Re: Optimizer oddness, possibly compounded in 8.1 |
|Previous:||From: Tom Lane||Date: 2005-12-03 00:37:49|
|Subject: Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits |