I've been working on getting the system to pass regression tests cleanly
when forcing a cache flush at every possible instant. The main tests
pass now (in 8.1 --- HEAD remains broken pending lookup_rowtype_tupdesc
fix), but contrib is still crashing. On investigation the problem turns
out to be in index_getprocinfo(), which tries to load up a cached
FmgrInfo for an index support function. If the support function is not
a built-in C function, then fmgr_info() will need to open pg_proc to
look it up. If a cache flush occurs in the course of that lookup,
the FmgrInfo we're trying to store into goes away! Havoc ensues of
course.
After looking at this for a bit, it seems the cleanest fix is for
RelationClearRelation() to treat any open index the same way it
currently handles nailed indexes --- ie, don't do anything except
re-read the pg_class record. Then we won't try to flush and rebuild the
cached index support info, and the problem doesn't arise.
This would still support REINDEX (which changes pg_class.relfilenode in
order to replace the physical file) and ALTER INDEX SET TABLESPACE.
But you couldn't make any meaningful changes in the definition of an
index, such as changing its column set, operator classes, partial-index
predicate, etc, except by dropping and recreating it.
Now this is true today, and it doesn't seem likely to me that we'd
ever want to relax it (since any such change would probably require
rebuilding the index anyway). But does anyone see that differently?
regards, tom lane
