Re: BUG #14781: server process was terminated by signal 11: Segmentation fault

Thanks for pointing to the possible root cause.
Our Dev team finally have figured out what was the reason and fixed it.
The reason was in using postgres_fdw based cursors like

for scr in (select f1, f2 ... from foreign table (postgre_fdw) ) loop

from scr1 in (select .. from foreign table (postgre_fdw) where ... = scr.f1) loop

Compicated update of local table using foreign tables as source

update of foreign table one record /**/
end loop;
end loop;

Dev team has refactored it to use loop based on arrays instead of fdw to reduce time of foreign session

MAKSIM KARABA

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, August 16, 2017 7:57 PM
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Maksim Karaba <Maksim_Karaba(at)epam(dot)com>; pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #14781: server process was terminated by signal 11: Segmentation fault

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> If you want to push this forward rather than wait for somebody else
>> to hit the problem, you could try adding something like
>>
>> if (fsplan->scan.scanrelid == 0 && outerPlanState(node) == NULL &&
>> (estate->es_plannedstmt->commandType != CMD_SELECT ||
>> estate->es_rowMarks))
>> elog(WARNING, "foreign join plan lacks EPQ support");
>>
>> near the beginning of postgresBeginForeignScan and then running your
>> app on a test server.

> Hmm, is there a reason this cannot be included as a sanity check always?

That's off-the-cuff rather than something I'm sure is correct. But yeah, I was wondering about pushing something like that into the standard code.

regards, tom lane