Re: WIP: getting rid of the pg_database flat file - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: getting rid of the pg_database flat file
Date
Msg-id 20090.1250095617@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: getting rid of the pg_database flat file  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: WIP: getting rid of the pg_database flat file  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Alpha 1 release notes
Next
From: Fujii Masao
Date:
Subject: Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args