Maksim Karaba <Maksim_Karaba@epam.com> writes:
> Unfortunately we cannot reproduce this issue on other servers, only on production system.
> And we cannot provide internal database info, schema structure and tables info.
[ shrug... ] We may just have to wait for somebody to be more
forthcoming.
FWIW, the stack trace seems to indicate that an incorrect plan has been
generated, ie one that has a remote join node without an EPQ recheck
subplan. That mistake in itself is probably pretty deterministic. The
reason you can't reproduce the crash easily is that the lack of a subplan
only manifests as a crash if we enter the EPQ recheck code, and that only
happens if the query tries to update a row that's just been updated by
some concurrent query. So it's not going to crash except under concurrent
load, which probably also explains why the bug wasn't found long ago.
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. I'm not sure offhand that the estate filters are
exactly right, but any statement that produces this warning would be
pretty suspect. At that point you could work on sanitizing the query +
tables + test data to get to a publishable test case; you could probably
boil your real query down quite a bit and still get the failure.
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
