Chasing a problem identified by my Salesforce colleagues led me to the conclusion that my commit f3b5565dd ("Use a safer method for determining whether relcache init file is stale") is rather borked. It causes pg_trigger_tgrelid_tgname_index to be omitted from the relcache init file, because that index is not used by any syscache. I had been aware of that actually, but considered it a minor issue. It's not so minor though, because RelationCacheInitializePhase3 marks that index as nailed for performance reasons, and includes it in NUM_CRITICAL_LOCAL_INDEXES. That means that load_relcache_init_file *always* decides that the init file is busted and silently(!) ignores it. So we're taking a nontrivial hit in backend startup speed as of the last set of minor releases.
Clearly, my shortcut of defining the init file contents as exactly the set of syscache-supporting rels was too short. I think the cleanest fix is to create a wrapper function in relcache.c that encapsulates the knowledge that pg_trigger_tgrelid_tgname_index is also to be included in the init file. But to prevent this type of problem from recurring, we need some defenses against the wrapper getting out of sync with reality elsewhere. I suggest that: 1. write_relcache_init_file ought to bitch if it concludes that a nailed relation is not to be written to the init file. Probably an Assert is enough. 2. load_relcache_init_file ought to complain if it takes the "wrong number of nailed relations" exit path. Here, it seems like there might be a chance of the path being taken validly, for example if a minor release were to decide to nail a rel that wasn't nailed before, or vice versa. So what I'm thinking about here is an elog(WARNING) complaint, which would make logic bugs like this pretty visible in development builds. If we ever did make a change like that in a minor release, people might get a one-time WARNING when upgrading, but I think that would be acceptable. Thoughts, better ideas? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers