global.bki vs template1.bki init files - Mailing list pgsql-hackers

From Tom Lane
Subject global.bki vs template1.bki init files
Date
Msg-id 14468.992302117@sss.pgh.pa.us
Whole thread Raw
Responses Re: global.bki vs template1.bki init files  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alex Pilosov
Date:
Subject: Re: Re: REPLACE INTO table a la mySQL
Next
From: Bruce Momjian
Date:
Subject: Re: global.bki vs template1.bki init files