=?gb2312?B?v7XHxca9?= <KANGQIAOPING754@pingan.com.cn> writes:
> I encountered segmentation fault when executing the sql statement of the query.
Hm...
> #0 pg_detoast_datum_packed (datum=0x0) at fmgr.c:1951
> #1 0x0000000000806fa2 in text_to_cstring (t=0x0) at varlena.c:185
> #2 0x0000000000831845 in FunctionCall1Coll (flinfo=<optimized out>, collation=collation@entry=0, arg1=<optimized
out>)at fmgr.c:1123
> #3 0x000000000083293a in OutputFunctionCall (flinfo=<optimized out>, val=<optimized out>) at fmgr.c:1755
This isn't terribly helpful. It seems that the query has returned a text
datum that's actually a null (zero) pointer, but where that came from is
impossible to tell at this very late stage of query execution.
> This problem can be temporarily solved after executing the command set max_parallel_workers_per_gather=0.
That's pretty interesting, but again, not very useful for localizing
the source of the issue. Parallel query invokes a *lot* of code that
is not in the non-parallel path.
The first thing I'd note is that 11.3 is five minor releases ago
(and it'll be six minor releases out of date by the end of the week).
So really the *first* thing you ought to do is update to 11.8 to see
if this is already fixed.
If it turns out it's not fixed, is there any chance of showing us a
self-contained test case?
regards, tom lane
