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: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autovacuum launcher using InitPostgres
Date: 2009-08-31 15:47:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> This just seems truly messy :-(.  Let me see if I can find something
>> cleaner.

> 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.

>> BTW, is it *really* the case that the AV launcher won't need
>> RecentGlobalXmin?  The way the HOT stuff works, I think anything that
>> examines heap pages at all had better have that set.

> Ugh.  I forgot about that.

We could possibly put

	if (IsAutovacuumLauncher())

right after the RelationCacheInitializePhase2 call.  No uglier than
what's here, for sure.

While I was looking at this I wondered whether
RelationCacheInitializePhase2 really needs to be inside the startup
transaction at all.  I think it could probably be moved up before
that.  However, if the AV launcher has to do GetTransactionSnapshot
then it's not clear that improves matters anyway. 

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Jeff JanesDate: 2009-08-31 15:48:19
Subject: Re: XLogFlush
Previous:From: Alvaro HerreraDate: 2009-08-31 15:38:16
Subject: Re: autovacuum launcher using InitPostgres

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