Tom, Thanks for getting in touch. Unfortunately, I thought to myself "why not drop the db in single mode under database postgres", which I did, and which worked, and thus, I can no longer produce the error, nor can I query the "phantom" table as you suggested. I can say that when I tried to vacuum the table, it told me:
backend> vacuum annual_data_gwreplace ERROR: relation "annual_data_gwreplace" does not exist STATEMENT: vacuum annual_data_gwreplace I restored, and now, I *think* things are going OK. Thanks again, r.b. >If there is a row in pg_class that for some reason didn't get deleted >when the table was dropped, you could just manually remove that row >(ie, DELETE FROM pg_class WHERE ... as superuser). You'd still need >another VACUUM to get the database's datfrozenxid updated, but >after that things should be OK. -- -- Robert W. Burgholzer http://www.findingfreestyle.com/ -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
