Re: unnecessary creation of FSM files during bootstrap mode

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: unnecessary creation of FSM files during bootstrap mode
Дата
Msg-id 29337.1547163057@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: unnecessary creation of FSM files during bootstrap mode  (John Naylor <jcnaylor@gmail.com>)
Ответы Re: unnecessary creation of FSM files during bootstrap mode  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
John Naylor <jcnaylor@gmail.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.kapila16@gmail.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: MERGE SQL statement for PG12
Следующее
От: Andres Freund
Дата:
Сообщение: Remove all "INTERFACE ROUTINES" style comments