Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
