From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "John P(dot) Looney" <valen(at)tuatha(dot)org> |
Cc: | postgres <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Postgres db corrupted ? |
Date: | 2003-07-29 14:38:50 |
Message-ID: | 21943.1059489530@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"John P. Looney" <valen(at)tuatha(dot)org> writes:
> What's up here ? Google is deathly silent.=20
> bash-2.05a$ pg_dumpall > db.out
> connected to template1...
> dumping database "MyPgSQLTest"...
> dumping database "bb1"...
> dumping database "bbadmin"...
> pg_dump: [archiver (db)] connection to database "bbadmin" failed: FATAL
> 1: SetDatabaseEncoding(): invalid database encoding
> pg_dump failed on bbadmin, exiting
A quick-and-dirty nostrum that sometimes helps for this sort of thing
is "vacuum full pg_database". (The idea is to get rid of dead tuples
that a new backend might be accidentally picking instead of the live
ones --- it has to read pg_database before it's joined the PROC array,
which among other things means it can't tell 100% accurately which rows
are really committed.)
If no go, could we see the output of "select * from pg_database"?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ragnar Kjrstad | 2003-07-29 15:16:11 | Re: Replication/Failover/HA solution |
Previous Message | Dani Oderbolz | 2003-07-29 14:05:09 | Re: Partition DB Tables by month |