a segfault failure of query

hi all

I encountered segmentation fault when executing the sql statement of the query.

I opened the software debug option and reproduced the problem, use the gbd debugging to capture the stack information as follows:
$ gdb $dir/11.3_debug/bin/postgres core.402790
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /paic/postgres/base/11.3_debug/bin/postgres...done.
[New LWP 402790]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `postgres: dbtest: postgres test1 [local] SELECT '.
Program terminated with signal 11, Segmentation fault.
#0 pg_detoast_datum_packed (datum=0x0) at fmgr.c:1951
1951 fmgr.c: No such file or directory.
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-8.el7.x86_64 libcom_err-1.42.9-10.0.1.el7.x86_64 libselinux-2.5-11.el7.x86_64 libxml2-2.9.1-6.0.1.el7_2.3.x86_64 openssl-libs-1.0.2k-12.0.1.el7.x86_64 pcre-8.32-17.el7.x86_64 xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) bt
#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(at)entry=0, arg1=<optimized out>) at fmgr.c:1123
#3 0x000000000083293a in OutputFunctionCall (flinfo=<optimized out>, val=<optimized out>) at fmgr.c:1755
#4 0x0000000000489e89 in printtup (slot=0x2b61018, self=0x2ba7f28be438) at printtup.c:434
#5 0x00000000005f6380 in ExecutePlan (execute_once=<optimized out>, dest=0x2ba7f28be438, direction=<optimized out>, numberTuples=0, sendTuples=true,
operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x2b47650, estate=0x2b47410) at execMain.c:1762
#6 standard_ExecutorRun (queryDesc=0x2b45b50, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:364
#7 0x00002ba68bd11fe5 in pgss_ExecutorRun (queryDesc=0x2b45b50, direction=ForwardScanDirection, count=0, execute_once=<optimized out>)
at pg_stat_statements.c:892
#8 0x00002ba68bf1959e in explain_ExecutorRun (queryDesc=0x2b45b50, direction=ForwardScanDirection, count=0, execute_once=<optimized out>)
at auto_explain.c:268
#9 0x000000000072e0bb in PortalRunSelect (portal=portal(at)entry=0x2a8b870, forward=forward(at)entry=true, count=0, count(at)entry=9223372036854775807,
dest=dest(at)entry=0x2ba7f28be438) at pquery.c:932
#10 0x000000000072f3d0 in PortalRun (portal=portal(at)entry=0x2a8b870, count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=true,
run_once=run_once(at)entry=true, dest=dest(at)entry=0x2ba7f28be438, altdest=altdest(at)entry=0x2ba7f28be438,
completionTag=completionTag(at)entry=0x7ffdef80dc90 "") at pquery.c:773
#11 0x000000000072b477 in exec_simple_query (
query_string=0x29fecd0 "SELECT\n CASE\nWHEN field1 = 'YxxxTyyyl' THEN\n '?'\nWHEN field1 IN ('Y1', 'Y2') THEN\n '??'\nWHEN field1 IN ('X1', 'X2', 'X3', 'X4') THEN\n '?'\nWHEN field1 IN (\n '01',\n"...) at postgres.c:1145
#12 0x000000000072c712 in PostgresMain (argc=<optimized out>, argv=argv(at)entry=0x2a384e0, dbname=0x2a383c8 "test1", username=<optimized out>)
at postgres.c:4182
#13 0x000000000047e3c3 in BackendRun (port=0x2a2aa40) at postmaster.c:4358
#14 BackendStartup (port=0x2a2aa40) at postmaster.c:4030
#15 ServerLoop () at postmaster.c:1707
#16 0x00000000006c36d9 in PostmasterMain (argc=argc(at)entry=3, argv=argv(at)entry=0x29f8f80) at postmaster.c:1380
#17 0x000000000047ee3b in main (argc=3, argv=0x29f8f80) at main.c:228

I try to rewrite the sql content and test it. It is suspected to be related to the automatic parallel execution of the execution plan.
This problem can be temporarily solved after executing the command set max_parallel_workers_per_gather=0.

Please help to see if there is a patch to fix this problem.

Regards.

********************************************************************************************************************************
The information in this email is confidential and may be legally privileged. If you have received this email in error or are not the intended recipient, please immediately notify the sender and delete this message from your computer. Any use, distribution, or copying of this email other than by the intended recipient is strictly prohibited. All messages sent to and from us may be monitored to ensure compliance with internal policies and to protect our business.
Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks.

收发邮件者请注意：
本邮件含涉密信息，请保守秘密，若误收本邮件，请务必通知发送人并直接删去，不得使用、传播或复制本邮件。
进出邮件均受到本公司合规监控。邮件可能发生被截留、被修改、丢失、被破坏或包含计算机病毒等不安全情况。
********************************************************************************************************************************