I wrote: > ... This means the only thing stopping us from > taking lock before we invoke relcache is lack of knowledge about the > rel's relisshared status. Given that the set of shared relations is > pretty small, and fixed in any given backend version, it wouldn't be > unreasonable to handle this by keeping a hardwired list of shared > relation OIDs somewhere in the backend.
On further investigation, there is one small stumbling block in that plan. We currently have hard-wired OIDs for shared catalogs and their indexes ... but not for their toast tables (nor the indexes thereon). I think the best solution for this might be to put the responsibility for creating system catalogs' toast tables into the bootstrap phase instead of making initdb do it afterwards. This would be a Good Thing anyway since currently we are incapable of dealing with bootstrap-time insertions of values large enough to need toasting. I'm imagining adding macros to the include/catalog/*.h files along the lines of TOAST_CATALOG(pg_class,4242,4243) where the numbers are hand-assigned OIDs for the toast table and index. The existing mechanisms for creating the .bki bootstrap script would turn these into commands in the .bki script. We could then get rid of ALTER TABLE ... CREATE TOAST TABLE as a SQL command altogether, which seems like a good thing to me. Anyone want to argue for keeping it? There really shouldn't be any case where a user needs to invoke it. Thoughts, objections? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match