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: 2702.1251733673@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:
> 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())
{
CommitTransactionCommand();
return;
}

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2009-08-31 15:48:19 Re: XLogFlush
Previous Message Alvaro Herrera 2009-08-31 15:38:16 Re: autovacuum launcher using InitPostgres