Re: global.bki vs template1.bki init files

> I have run into a small snag with adding indexes to pg_shadow: the first
> attempt to run a non-bootstrap-mode backend fails with 'user "postgres"
> does not exist'. The reason it fails is that user postgres is added
> to pg_shadow by global.bki, which is run after template1.bki, which is
> where all the bootstrap-time indexes are created and filled. So user
> postgres is in pg_shadow, but it's not in the indexes, which means that
> a syscache-driven attempt to look it up will fail.
>
> I could hack around this by moving bootstrap index creation to the end
> of global.bki instead of template1.bki. However, this just begs the
> question of why we have two init scripts at all. The distinction
> between global and local objects is not determined by these scripts
> (IsSharedSystemRelationName is where that gold is hidden). We've
> already got template1.bki creating some global objects (namely the
> indexes on pg_group), and if I make the quick-hack fix then we'll
> instead have global.bki creating a whole bunch of non-global indexes
> along with a few global ones.
>
> I'm strongly inclined to merge global.bki and template1.bki into a
> single initialization script, say postgres.bki. Comments?

I thought we agreed to merge them already. Also, could we modify
IndexScanOK() to catch this case and do a heap scan?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026