Re: unnecessary creation of FSM files during bootstrap mode

John Naylor <jcnaylor(at)gmail(dot)com> writes:
> Thought I'd ping...

Sorry, I'd not been paying attention to this thread.

> On Sat, Dec 15, 2018 at 12:02 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> As pointed out by John Naylor [1], it seems during bootstrap mode, we
>> are always creating FSM files which are not required. In commit's
>> b9d01fe288 and 3908473c80, we have added some code where we allowed
>> the creation of files during mdopen even if they didn't exist during
>> the bootstrap mode. The comments in the code say: "During bootstrap,
>> there are cases where a system relation will be accessed (by internal
>> backend processes) before the bootstrap script nominally creates it."
>> I am sure this will be the case when that code is added but is it
>> required today?

I'm surprised to hear that it isn't, but if we get through initdb
then it must not be. The special case was certainly still necessary
as of 3908473c80, for the BKI_BOOTSTRAP catalogs. It didn't bother me
at the time that those were special --- how are you going to create
pg_class, in particular, without cheating like mad? But I guess we must
have cleaned up something in higher levels of bootstrapping to the point
where those do get mdcreate'd in advance of being opened.

It's also possible that you just aren't exercising the cases where
trouble occurs. In particular, noting this bit in InsertOneValue():

/*
* We use ereport not elog here so that parameters aren't evaluated unless
* the message is going to be printed, which generally it isn't
*/
ereport(DEBUG4,
(errmsg_internal("inserted -> %s",
OidOutputFunctionCall(typoutput, values[i]))));

I'd counsel running initdb under DEBUG4 or higher before deciding
you're out of the woods.

(If that does turn out to be a problem, and it's the only problem,
we could discuss whether we really need that debug message at all.)

regards, tom lane