Re: Re: Vaccuuming every db in cluster fails to eliminate "execute a full-database VACUUM in..."

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/