| From: | Scott Ribe <scott_ribe(at)killerbytes(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Can't pg_dumpall, claims database exists twice |
| Date: | 2005-03-28 18:05:40 |
| Message-ID: | BE6D9584.1F43C%scott_ribe@killerbytes.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> Now how the heck did that happen? That's not some kind of weird UPDATE
> failure, because the rows have different OIDs ... it seems like the
> newer row must have been explicitly inserted, and it should surely have
> been blocked by the unique index on datname. Are there subdirectories
> under $PGDATA/base for both of those OIDs?
No, in fact there is only template1, template0, and 1 of the pedcard
instances. Am I right that this simplifies things greatly? That what I have
here is a single database with all the data in it, and some phantom entry in
pg_database that cannot possibly be used anywhere since it lacks associated
data files?
Could you give me an outline of how to clean this up? Should I be looking at
other catalog info to see if there are components of the db that are also
duplicated? Or should I just delete the bogus pg_database entry, then dump
and restore?
--
Scott Ribe
scott_ribe(at)killerbytes(dot)com
http://www.killerbytes.com/
(303) 665-7007 voice
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Ribe | 2005-03-28 18:08:54 | Re: Can't pg_dumpall, claims database exists twice |
| Previous Message | Ed L. | 2005-03-28 18:03:34 | Re: LWM 2004 Readers' Choice Nomination |