Re: strange behavior (corruption?) of large production

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: strange behavior (corruption?) of large production
Дата
Msg-id 4390E98F.6010508@joeconway.com
обсуждение исходный текст
Ответ на Re: strange behavior (corruption?) of large production database  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: strange behavior (corruption?) of large production database  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: Re: Optimizer oddness, possibly compounded in 8.1
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Optimizer oddness, possibly compounded in 8.1