Beta2 Vacuum and pg_dump failures and mangled databases
От | Frank Joerdens |
---|---|
Тема | Beta2 Vacuum and pg_dump failures and mangled databases |
Дата | |
Msg-id | 3A5F3945.DC213B19@joerdens.de обсуждение исходный текст |
Ответы |
Re: Beta2 Vacuum and pg_dump failures and mangled databases
Re: Beta2 Vacuum and pg_dump failures and mangled databases |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: