Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-08-31 16:18:55
Subject: Re: autovacuum launcher using InitPostgres
Previous:From: Tom LaneDate: 2009-08-31 16:07:51
Subject: Re: autovacuum launcher using InitPostgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group