Re: unnecessary creation of FSM files during bootstrap mode - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: unnecessary creation of FSM files during bootstrap mode
Date
Msg-id CAA4eK1L4cQiPotYh4rYycHVY6+NSmB1ip350s6XkS-Q2fjFQXg@mail.gmail.com
Whole thread Raw
In response to Re: unnecessary creation of FSM files during bootstrap mode  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: unnecessary creation of FSM files during bootstrap mode  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 11, 2019 at 5:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
>

I have tried initdb with --debug option (If I am not wrong, it runs
initdb under DEBUG5 mode) and didn't hit any problem after applying
the patch.  Are you expecting that we might try to open pg_proc at
that place which can lead to the problem?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: Displaying and dumping of table access methods
Next
From: Etsuro Fujita
Date:
Subject: Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0