Re: Why corruption memory in one database affects all the cluster?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Why corruption memory in one database affects all the cluster?
Дата
Msg-id CAMkU=1yD0XkBihx+Hna9R=F-APqv=BfZQcoqX82sZuVa1PaeGQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why corruption memory in one database affects all the cluster?  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-general
On Mon, Jul 14, 2014 at 1:20 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Sun, Jul 13, 2014 at 12:07 PM, Ru Devel <rudevel@gmail.com> wrote:
Hello, 

I have postgres 9.3.4 running on linux, and ~20 databases in the cluster.

All the cluster was migrated from 9.2 using pg_upgradecluster.

After migration autovacuum started to fail in one database, causing entire cluster crashes:


2014-07-13 21:16:24 MSK [5665]: [1-1] db=,user= PANIC:  corrupted item pointer: offset = 5292, size = 24
2014-07-13 21:16:24 MSK [29131]: [417-1] db=,user= LOG:  server process (PID 5665) was terminated by signal 6: Aborted
2014-07-13 21:16:24 MSK [29131]: [418-1] db=,user= DETAIL:  Failed process was running: autovacuum: VACUUM public.postfix_stat0 (to prevent wraparound)


 
If your top concern is getting all the other databases back as soon as possible, you should be able to just drop the corrupted database (after making a full backup).  Then you can worry about recovering that database and rejoining it at your leisure.

Actually It looks like just doing a "REINDEX TABLE public.postfix_stat0" could get you back and running again, assuming the corruption hadn't spread from its origin to other places.

Cheers,

Jeff

В списке pgsql-general по дате отправления:

Предыдущее
От: Néstor Boscán
Дата:
Сообщение: Quering complete PLPGSQL code
Следующее
От: Jerry Sievers
Дата:
Сообщение: Re: Quering complete PLPGSQL code