First I tried to dump out a database like:

frank@limedes:~ > pg_dump mpi > dump.mpi
getTables(): relation 'institute': 6 Triggers were expected, but got 0

The database mpi does contain a table 'institute' and a few foreign key constraints. Then
I tried to dump another database, as in:

postgres@limedes:~ > pg_dump intranet > dumptest
getTables(): relation 'institute': 6 Triggers were expected, but got 0

The database intranet has _no_ table 'institute' and no foreign key constraints.

Then I had a look via psql at intranet and it turns out that it shows up as the database
mpi mangled into the database intranet, contentwise; i.e. it doesn't only show the tables
that are in intranet but also those that belong to mpi?! Then I look at _any_ of the
databases in this Postgres installation, they show up as mangled together with mpi?! When
I try to vacuum any of those databases, I always get:

[ . . . stuff that looks normal . . . ]
 Index pg_class_oid_index: Pages 2; Tuples 138: Deleted 45. CPU 0.00s/0.00u sec.
NOTICE:  Index pg_class_oid_index: NUMBER OF INDEX' TUPLES (138) IS NOT THE SAME AS HEAP'
(205).
        Recreate the index.
NOTICE:  Index pg_class_relname_index: Pages 4; Tuples 138: Deleted 44. CPU 0.00s/0.00u
sec.
NOTICE:  Index pg_class_relname_index: NUMBER OF INDEX' TUPLES (138) IS NOT THE SAME AS
HEAP' (205).
        Recreate the index.
ERROR:  Cannot insert a duplicate key into unique index pg_class_relname_index

However, if I use another client, i.e. not psql, but a web app, then I do still have
access to the contents of, for instance, the intranet database.

Restarting the server didn't make a difference.

Does this make any sense to anyone?

Regards, Frank

Fri, 12 Jan 2001 18:05:09 +0100
Frank Joerdens <frank@joerdens.de>
Beta2 Vacuum and pg_dump failures and mangled databases
Frank Joerdens wrote:
[ . . . ]
> Restarting the server didn't make a difference.

I upgraded to beta3 just now and the problem persists. I didn't do an initdb obviously cuz
I cannot save the data via pg_dump. Beta3 will read beta2 data OK (I guess this means that
an initdb is not required when going from beta2 to beta3?!) but I can't vacuum or dump on
any database.

- Frank

Fri, 12 Jan 2001 20:13:16 +0100
Frank Joerdens <frank@joerdens.de>
Re: Beta2 Vacuum and pg_dump failures and mangled databases
On Fri, Jan 12, 2001 at 06:05:09PM +0100, Frank Joerdens wrote:
[ . . . ]
> Does this make any sense to anyone?

Are questions related to 7.1 beta versions best directed to hackers or to
general?

- Frank

Fri, 12 Jan 2001 20:28:00 +0100
Frank Joerdens <frank@joerdens.de>
Re: Beta2 Vacuum and pg_dump failures and mangled databases
Frank Joerdens <frank@joerdens.de> writes:
> Then I had a look via psql at intranet and it turns out that it shows
> up as the database mpi mangled into the database intranet,
> contentwise; i.e. it doesn't only show the tables that are in intranet
> but also those that belong to mpi?

I think you've been bit by the RelFileNodeEquals bug we found on Monday.
One of the known possible effects of that bug is that a VACUUM can write
blocks of system-catalog tables into the same catalog of a different
database.

You should probably write off your databases as toast ... update to
beta3 and do an initdb.  Sorry about that ...

			regards, tom lane

Fri, 12 Jan 2001 14:35:34 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Beta2 Vacuum and pg_dump failures and mangled databases 
Frank Joerdens <frank@joerdens.de> writes:
> Are questions related to 7.1 beta versions best directed to hackers or to
> general?

hackers is the proper place for discussing any unreleased version, I'd
say.  Or you can file a bug report on pgsql-bugs, if that seems more
appropriate.

			regards, tom lane

Fri, 12 Jan 2001 14:37:10 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Beta2 Vacuum and pg_dump failures and mangled databases 