Re: [HACKERS] Optimizer fed bad data about some system-table indexes

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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