global.bki vs template1.bki init files
От | Tom Lane |
---|---|
Тема | global.bki vs template1.bki init files |
Дата | |
Msg-id | 14468.992302117@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: global.bki vs template1.bki init files
|
Список | 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 по дате отправления: