From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | mpokky(at)126(dot)com |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Re: Re: Bug: ERROR: invalid cache ID: 42 CONTEXT: parallel worker |
Date: | 2018-08-25 03:19:10 |
Message-ID: | CAA4eK1JQdeodo=K6TEe8Jf84wyZ6zR6Lckn=nQxdg7_Nk95HMQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Aug 24, 2018 at 11:35 AM jimmy <mpokky(at)126(dot)com> wrote:
>
> I create two normal postgresql tables, and import datas from two foreign tables.
> Then I use four normal postgresql tables to query data, and it still throw these errors, after that I am afraid that it maybe is not connection with oracle fdw.
>
So, can we assume that there is no fdw involved in the query that is
generating an error? Can you share the plan (Explain Analyze or
Explain output) of the query?
> In these tables, one table has over 200 fields, and the other two tables, each table has over 800 fields.
> When I use left join, Would that be the problem that caused this.
>
I am not sure but there is no apparent reason why on using some form
of join, it throws such an error. I think we can make better progress
if you get us the call stack of the parallel worker/'s. I can see
above that you have got the call stack, but it is from the master
backend and the error is generated in the parallel worker. Thomas has
already suggested a way to get the call stack, if you can do that, it
would be great. I think we can help you to get the call stack if you
are facing any problem, have you tried getting it?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Kukushkin | 2018-08-25 07:54:39 | Re: BUG #15346: Replica fails to start after the crash |
Previous Message | Bruce Momjian | 2018-08-25 02:04:18 | Re: BUG #15345: pg_upgrade from 9.6.10 to 10.5 fails due to function call in index definition |