While looking at the pending patch to clean up management of
rd_partcheck, I noticed that RelationCacheInitializePhase3 has code that
purports to reload rd_partkey and rd_partdesc, but none for rd_partcheck.
However, that reload code is dead code, as is easily confirmed by
checking the code coverage report, because we have no partitioned system
catalogs.
Moreover, if somebody tried to add such a catalog, I'd bet a good deal
of money that this code would not work. It seems highly unlikely that
we could run RelationBuildPartitionKey or RelationBuildPartitionDesc
successfully when we haven't even finished bootstrapping the relcache.
I don't think that this foolishness is entirely the fault of the
partitioning work; it's evidently modeled on the adjacent code to reload
rules, triggers, and row security code. But that code is all equally
dead, equally unlikely to work if somebody tried to invoke it, and
equally likely to be forever unused because there are many other
problems you'd have to surmount to support something like triggers or
row security on system catalogs.
I'm inclined to remove almost everything below the comment
"Fix data that isn't saved in relcache cache file", and replace
it with either assertions or test-and-elogs that say that a
relation appearing in the cache file can't have triggers or rules
or row security or be partitioned.
I am less sure about whether the table-access-method stanza is as silly
as the rest, but I do see that it's unreached in current testing.
So I wonder whether there is any thought that we'd realistically support
catalogs with nondefault AMs, and if there is, does anyone think that
this code would work?
regards, tom lane