Re: autovacuum launcher using InitPostgres

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autovacuum launcher using InitPostgres
Date: 2009-08-31 16:15:20
Message-ID: 3185.1251735320@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Heikki Linnakangas wrote:
>> 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.

The part I was unhappy about was falling out with the startup
transaction still open (which the patch as written didn't do, but
would have needed to given the snapshot issue). I don't object to
trying to restructure InitPostgres along the above lines if it can be
done cleanly. But on the third hand, Alvaro's right that there isn't
any other obvious use for it.

We've also got the client_encoding (GUC initialization timing) issue
to fix in this area. I suggest that any major restructuring-for-beauty
wait till after the dust settles. I think what we have here (in the
revised patch) is ugly but not too ugly to live with.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-31 16:18:55 Re: autovacuum launcher using InitPostgres
Previous Message Tom Lane 2009-08-31 16:07:51 Re: autovacuum launcher using InitPostgres