Re: [BUGS] 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@sss.pgh.pa.us]
Sent: Wednesday, August 16, 2017 7:57 PM
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Maksim Karaba <Maksim_Karaba@epam.com>; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #14781: server process was terminated by signal 11: Segmentation fault

Alvaro Herrera <alvherre@2ndquadrant.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
thatinto the standard code. 
        regards, tom lane


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs