Thread: 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?
regards, tom lane
> 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
> 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
]> > 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, Pennsylvania19026
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
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