"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> One thing we'd have to work out is that the critical system tables
>> (eg, pg_class itself, as well as its indexes) would have to have
>> predictable physical names.
> The only limitation of the relation filename is the uniqueness.
> So it doesn't introduce any inconsistency that system tables
> have fixed name.
> As for system relations it wouldn't be so bad because CLUSTER/
> ALTER TABLE DROP COLUMN ... would be unnecessary(maybe).
> But as for system indexes,it is preferable that VACUUM/REINDEX
> could rebuild them safely. System indexes never shrink currently.
Right, it's the index-shrinking business that has me worried.
Most of the other reasons for swapping in a new file don't apply
to system tables, but that one does.
One possibility is to say that system *tables* can't be reversioned
(at least not the critical ones) but system *indexes* can be.
Then we'd have to use your ignore-system-indexes stuff during backend
startup, until we'd found out where the indexes are. Might be too big
a time penalty however... not sure. Shared cache inval of a system
index could be a little tricky too; I don't think the catcache routines
are prepared to fall back to non-index scan are they?
On the whole it might be better to cheat by using a side data structure
like the pg_internal.init file, that a backend could consult to find out
where the indexes are now.
regards, tom lane