Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@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