Re: unnecessary creation of FSM files during bootstrap mode

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John Naylor <jcnaylor(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: unnecessary creation of FSM files during bootstrap mode
Date: 2019-01-11 12:39:31
Message-ID: CAA4eK1L4cQiPotYh4rYycHVY6+NSmB1ip350s6XkS-Q2fjFQXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 11, 2019 at 5:00 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2019-01-11 12:50:19 Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
Previous Message Amit Khandekar 2019-01-11 11:23:47 Re: Displaying and dumping of table access methods