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: 4390E98F.6010508@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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:
> 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

In response to

Responses

Browse pgsql-hackers by date

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