From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Paval <dani@scorpionsoftware.ro>
cc: pgsql-admin@postgresql.org
Subject: Re: Data corruption / recover
In-reply-to: <512F3562.9060609@scorpionsoftware.ro>
References: <512F3562.9060609@scorpionsoftware.ro>
Comments: In-reply-to Daniel Paval <dani@scorpionsoftware.ro>
	message dated "Thu, 28 Feb 2013 12:45:54 +0200"
Date: Thu, 28 Feb 2013 09:21:15 -0500
Message-ID: <4302.1362061275@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Daniel Paval <dani@scorpionsoftware.ro> writes:
> We're dealing with the following situation (PG version is 7.4.30): 

7.4?  I sure hope you're going to migrate onto something less obsolete
once you get out of this problem.  In any still-in-support release
series, autovacuum would have saved you from this.

> somehow, a DB has gone missing from pg_database (psql \l listing doesn't 
> show it anymore). More, while you can still \c to it, a \d table listing 
> only shows a fraction of the tables.

Transaction IDs in the system catalogs have wrapped around, so that some
rows appear to be "in the future" and thus invisible.

> A full vacuum _without_ the freeze option does make all databases, 
> tables and users visible, but duplicated, i.e. \l then shows the 
> database twice and a \d on the database lists all tables twice.

Not too surprising.  You'll need to examine each pair of duplicate
catalog rows, figure out which version is newer, and then delete the
older version.  (Use the ctid column to disambiguate.)  More than
likely, there are some duplicates in your data as well as in the system
catalogs, so I'm afraid you've got quite a bit of manual repair in front
of you.

			regards, tom lane


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin