Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> (a) why does the relcache need an initialization file for the system
>> index cache entries in the first place?
> The problem is cicurular too. Without those entries in the cache, the
> system can't do the lookups of the real tables.
But the init file is built on-the-fly the first time it is needed;
so it seems it can't be as circular as all that. If we *really* needed
hardcoded data then it would have to be done more like the way the
standard entries in pg_class and other sys tables are made. I think.
>> (b) if we can't just get rid of the init file, how about dropping and
>> rebuilding it at the end of the initdb process (after template1 has
>> been vacuumed)? Then at least it'd show a size of a few hundred for
>> pg_class, instead of zero.
> You can't drop them or you could never recreate them. Why does the
> vacuum analyze at the end of initdb not fix this? Is this because the
> cache bypasses pg_class and returns the hardcoded rows?
The vacuum analyze *does* fix the data that's in the pg_class entry
for the index. Trouble is that the relcache entry for the index is
never read from pg_class; it's loaded from this never-updated init file.
One possible answer is to rewrite the init file as the final step of
a vacuum, using the just-updated pg_class data. But I'm still not
convinced that we really need the init file at all...
regards, tom lane
