Re: WIP: getting rid of the pg_database flat file
От | Tom Lane |
---|---|
Тема | Re: WIP: getting rid of the pg_database flat file |
Дата | |
Msg-id | 20090.1250095617@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP: getting rid of the pg_database flat file (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: WIP: getting rid of the pg_database flat file
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Are you going to commit the current patch? We can remove the hacks that > support autovacuum later. I was thinking that InitPostgres could be > split in two, with the first half ending just after > RelationCacheInitializePhase2. Then workers could figure out their > database names and go off on the second half; regular backends would > just call the two halves directly. That way, the launcher could use the > first half. Yeah, I intend to commit what I have after I finish cleaning up a few loose ends (just found a bug with CLOBBER_CACHE_ALWAYS), and then we can take a look at making autovacuum play with it. I envision three or four commits before flatfiles.c can disappear. > (BTW I assume there is going to be an index on OID > available on pg_database after the shared relcache initialization?) Yeah. That's not in the patch I sent last night, but the OID index has to become nailed too in order to allow removing FindMyDatabaseByOid. However, I'm not sure that the AV launcher could touch it --- were you thinking that would be important? regards, tom lane
В списке pgsql-hackers по дате отправления: