Postgres Pro
Downloads
Home   >   mailing lists

Re: Why corruption memory in one database affects all the cluster? - Mailing list pgsql-general

From Jeff Janes
Subject Re: Why corruption memory in one database affects all the cluster?
Date
Msg-id CAMkU=1yD0XkBihx+Hna9R=F-APqv=BfZQcoqX82sZuVa1PaeGQ@mail.gmail.com
Whole thread Raw
In response to Re: Why corruption memory in one database affects all the cluster?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general
Tree view
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 by date:

Previous
From: Néstor Boscán
Date:
Subject: Quering complete PLPGSQL code
Next
From: Jerry Sievers
Date:
Subject: Re: Quering complete PLPGSQL code