Heikki Linnakangas wrote: > Tom Lane wrote: > > Alvaro Herrera <alvhe...@commandprompt.com> writes: > >> Tom Lane wrote: > >>> This just seems truly messy :-(. Let me see if I can find something > >>> cleaner. > > I quite like the idea of splitting initialization into two phases, one > that let's you access shared catalogs, and one to bind to a database. I > didn't look into the details, though.
The problem is that it only gives you access to pg_database, because the other shared catalogs require more relcache initialization than we do. So I'm not sure it'd be useful for anything else. > >> I was considering having InitPostgres be an umbrella function, so that > >> extant callers stay as today, but the various underlying pieces are > >> skipped depending on who's calling. For example I didn't like the bit > >> about starting a transaction or not depending on whether it was the > >> launcher. > > > > Yeah. If you have InitPostgres know that much about the AV launcher's > > requirements, it's not clear why it shouldn't just know everything. > > Having it return with the initial transaction still open just seems > > completely horrid. > > Yeah, that sounds messy. Can AV launcher simply open a 2nd initial > transaction? The main body of avlauncher opens a new transaction whenever it needs one. The problem is that the transaction in InitPostgres is closed in the second half -- the code I had was skipping StartTransactionCommand in the launcher case, but as Tom says that was wrong because it was failing to set RecentGlobalXmin. If we're looking at simplifing InitPostgres, one thing we could do is separate the part for the bootstrap process, which is like 10% of the work for a regular backend ... -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
