The version is 8.3.3, and I use autovacuum for the routine maintenance.
The ctid's are distinct
grande=# select oid, ctid, relname from pg_class where oid IN
(26770910, 26770918, 26770919, 26770920);
oid | ctid | relname
----------+---------+---------------------------------------
26770910 | (36,52) | availcpedata_20100410
26770918 | (36,42) | availcpedata_20100410_date_index
26770919 | (36,45) | availcpedata_20100410_pollgrpid_index
26770910 | (37,19) | availcpedata_20100410
(4 rows)
I will try deleting the one with (37,19) manually in the morning.
Thanks for the suggestion.
Woody
On Mon, Apr 19, 2010 at 1:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> George Woodring <george.woodring@iglass.net> writes:
>> Upon investigation I found that I have a table that is in the database twice
>
>> db=> select oid, relname from pg_class where oid IN (26770910,
>> 26770918, 26770919);
>> oid | relname
>> ----------+---------------------------------------
>> 26770910 | availcpedata_20100410
>> 26770918 | availcpedata_20100410_date_index
>> 26770919 | availcpedata_20100410_pollgrpid_index
>> 26770910 | availcpedata_20100410
>> (4 rows)
>
> It's not immediately clear whether that's really two instances of the
> row for availcpedata_20100410, or a false hit due to index corruption.
> If you include ctid in the query, do the rows have distinct ctids?
> If not, reindexing pg_class should fix it.
>
>> Can anyone suggest a strategy for removing the table? I don't want to
>> start randomly deleting stuff from the catalogs.
>
> If there are two, manually deleting one is the only way to fix it. Use
> the ctid to make sure you remove only one ...
>
> regards, tom lane
>
--
iGLASS Networks
www.iglass.net