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

Mon, 11 Jun 2001 19:28:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
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, Pennsylvania 19026

Mon, 11 Jun 2001 20:18:24 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: global.bki vs template1.bki init files
> I thought we agreed to merge them already.

We did?  Good.  Will make it so.

> Also, could we modify
> IndexScanOK() to catch this case and do a heap scan?

How?  Also, why?

			regards, tom lane

Mon, 11 Jun 2001 21:10:54 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: global.bki vs template1.bki init files 
]> > I thought we agreed to merge them already.
> 
> We did?  Good.  Will make it so.

I know Peter mentioned it a long time ago.

> > Also, could we modify
> > IndexScanOK() to catch this case and do a heap scan?
> 
> How?  Also, why?

I remember problems getting the index on pg_index because of recursive
lookups so I thought you could either have bootstrap mode ignore the
pg_shadow index or have recursion identified and fallback to heapscan,
but if you merge them there isn't much point.

-- 
  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, Pennsylvania 19026

Mon, 11 Jun 2001 21:14:03 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: global.bki vs template1.bki init files
Bruce Momjian writes:

> ]> > I thought we agreed to merge them already.
> >
> > We did?  Good.  Will make it so.
>
> I know Peter mentioned it a long time ago.

Somehow I got marked down for this but I actually thought the split was
useful.  One reason was that you could restore template1 individually
(which hasn't worked for a while).  Another was that you could have more
than one template initialization file, possibly even to initialize more
than one template database at boot time.  Obviously these things are never
used and there are other ways to achieve similar results, and given that
there is a pretty strong interdependency between what initdb does and what
the backend thinks it should do there's little need to fight for it.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter


Tue, 12 Jun 2001 16:42:56 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: global.bki vs template1.bki init files
Peter Eisentraut <peter_e@gmx.net> writes:
> Somehow I got marked down for this but I actually thought the split was
> useful.  One reason was that you could restore template1 individually
> (which hasn't worked for a while).

If it ever did, which seems doubtful given the way build_indices works;
there's no way to build only a subset of the existent indices.

Anyway, we have a superior solution for that problem now: you can delete
template1 and clone it from template0.  (Yes, that actually works...
at least it does if you have another database you can connect to while
issuing the DROP DATABASE and CREATE DATABASE commands...)

			regards, tom lane

Tue, 12 Jun 2001 10:54:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: global.bki vs template1.bki init files 