Re: autovacuum launcher using InitPostgres - Mailing list pgsql-hackers

From Tom Lane
Subject Re: autovacuum launcher using InitPostgres
Date
Msg-id 2702.1251733673@sss.pgh.pa.us
Whole thread Raw
In response to Re: autovacuum launcher using InitPostgres  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: autovacuum launcher using InitPostgres  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: autovacuum launcher using InitPostgres  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: autovacuum launcher using InitPostgres
Next
From: Jeff Janes
Date:
Subject: Re: XLogFlush