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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend