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
