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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026