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
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 |