Jeremy Drake <pgsql@jdrake.com> writes:
> Am I correct in interpreting this as the hash opclass for Oid?
No, it's the AMOPOPID catalog cache (containing rows from pg_amop
indexed by amopopr/amopclaid).
After digging around for a bit I noticed that catalog caches get
flushed if someone vacuums the associated catalog. I have a
theory now: somebody vacuumed pg_amop while this process had an
open CatCList of entries from this catcache. ResetCatalogCache
would mark both the CatCList and its member entries as "dead",
because they can't be released while the CatCList has a positive
refcount. When ReleaseCatCacheList is called, it would in turn
call CatCacheRemoveCList ... which would remove the list, but
it doesn't remove the member entries. That's a bug, because the
entries should go away if they're dead and no longer have any
reference counts keeping them in the "zombie" state.
However, AFAICS the only consequence of this bug is to trigger
that Assert failure if you've got Asserts enabled. Dead catcache
entries aren't actually harmful except for wasting some space.
So I don't think this is related to your pg_type duplicate key
problem.
One weak spot in this theory is the assumption that somebody was
vacuuming pg_amop. It seems unlikely that autovacuum would do so
since the table never changes (unless you had reached the point
where an anti-XID-wraparound vacuum was needed, which is unlikely
in itself). Do you have any background processes that do full-database
VACUUMs?
I'll go fix CatCacheRemoveCList, but I think this is not the bug
we're looking for.
regards, tom lane