Thread: BUG #17897: Crash on assignment to array of constraint-less domain over composite type

The following bug has been logged on the website:

Bug reference:      17897
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 15.2
Operating system:   Ubuntu 22.04
Description:

The following modified excerpt from regress/sql/domain.sql:
create type comptype as (cf1 int, cf2 int);
create domain dcomptype as comptype;

create table dcomptable (f1 dcomptype[]);
insert into dcomptable values (null);
update dcomptable set f1[1].cf2 = 5;

causes a server crash with the following stack trace:
Core was generated by `postgres: law regression [local] UPDATE
                        '.
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Section `.reg-xstate/3528026' in core file too small.
#0  0x000055b874aaa716 in pg_detoast_datum (datum=0x0) at fmgr.c:1710
1710            if (VARATT_IS_EXTENDED(datum))
(gdb) bt
#0  0x000055b874aaa716 in pg_detoast_datum (datum=0x0) at fmgr.c:1710
#1  0x000055b8746558c1 in ExecEvalFieldStoreDeForm (state=0x55b8766d9320,
op=0x55b8766d8d38, econtext=0x55b8766d8aa0)
    at execExprInterp.c:3160
#2  0x000055b874651bc8 in ExecInterpExpr (state=0x55b8766d9320,
econtext=0x55b8766d8aa0, isnull=0x7ffc96491aaf)
    at execExprInterp.c:1439
#3  0x000055b874652aca in ExecInterpExprStillValid (state=0x55b8766d9320,
econtext=0x55b8766d8aa0, 
    isNull=0x7ffc96491aaf) at execExprInterp.c:1826
#4  0x000055b87466d895 in ExecEvalExprSwitchContext (state=0x55b8766d9320,
econtext=0x55b8766d8aa0, 
    isNull=0x7ffc96491aaf) at ../../../src/include/executor/executor.h:341
#5  0x000055b87466d90d in ExecProject (projInfo=0x55b8766d9318) at
../../../src/include/executor/executor.h:375
#6  0x000055b87466ddec in ExecScan (node=0x55b8766d8870,
accessMtd=0x55b8746b1cca <SeqNext>, 
    recheckMtd=0x55b8746b1d73 <SeqRecheck>) at execScan.c:238
#7  0x000055b8746b1dcc in ExecSeqScan (pstate=0x55b8766d8870) at
nodeSeqscan.c:112
#8  0x000055b874669731 in ExecProcNodeFirst (node=0x55b8766d8870) at
execProcnode.c:464
#9  0x000055b8746a684d in ExecProcNode (node=0x55b8766d8870) at
../../../src/include/executor/executor.h:259
#10 0x000055b8746ac768 in ExecModifyTable (pstate=0x55b8766d8350) at
nodeModifyTable.c:3591
#11 0x000055b874669731 in ExecProcNodeFirst (node=0x55b8766d8350) at
execProcnode.c:464
#12 0x000055b87465c9ad in ExecProcNode (node=0x55b8766d8350) at
../../../src/include/executor/executor.h:259
#13 0x000055b87465f8b4 in ExecutePlan (estate=0x55b8766d80e0,
planstate=0x55b8766d8350, use_parallel_mode=false, 
    operation=CMD_UPDATE, sendTuples=false, numberTuples=0,
direction=ForwardScanDirection, dest=0x55b8766c4c98, 
    execute_once=true) at execMain.c:1636
#14 0x000055b87465d0e4 in standard_ExecutorRun (queryDesc=0x55b8766146a0,
direction=ForwardScanDirection, count=0, 
    execute_once=true) at execMain.c:363
#15 0x000055b87465cecf in ExecutorRun (queryDesc=0x55b8766146a0,
direction=ForwardScanDirection, count=0, 
    execute_once=true) at execMain.c:307
#16 0x000055b8748d5460 in ProcessQuery (plan=0x55b8766c43b8, 
    sourceText=0x55b8765f25a0 "update dcomptable set f1[1].cf2 = 5;",
params=0x0, queryEnv=0x0, dest=0x55b8766c4c98, 
    qc=0x7ffc96492090) at pquery.c:160
#17 0x000055b8748d7053 in PortalRunMulti (portal=0x55b87665ec70,
isTopLevel=true, setHoldSnapshot=false, 
    dest=0x55b8766c4c98, altdest=0x55b8766c4c98, qc=0x7ffc96492090) at
pquery.c:1277
#18 0x000055b8748d6536 in PortalRun (portal=0x55b87665ec70,
count=9223372036854775807, isTopLevel=true, run_once=true, 
    dest=0x55b8766c4c98, altdest=0x55b8766c4c98, qc=0x7ffc96492090) at
pquery.c:791
#19 0x000055b8748cf311 in exec_simple_query (query_string=0x55b8765f25a0
"update dcomptable set f1[1].cf2 = 5;")
    at postgres.c:1250
#20 0x000055b8748d4230 in PostgresMain (dbname=0x55b87661eaf8 "regression",
username=0x55b87661ead8 "law")
    at postgres.c:4593
#21 0x000055b8747f9551 in BackendRun (port=0x55b876616210) at
postmaster.c:4511
#22 0x000055b8747f8dd8 in BackendStartup (port=0x55b876616210) at
postmaster.c:4239
#23 0x000055b8747f4d65 in ServerLoop () at postmaster.c:1806
#24 0x000055b8747f44c2 in PostmasterMain (argc=3, argv=0x55b8765eda60) at
postmaster.c:1478
#25 0x000055b8746e81d3 in main (argc=3, argv=0x55b8765eda60) at main.c:202

Not reproduced on REL_11_STABLE, but reproduced on REL_12_STABLE .. master
since 04fe805a1 made a constraint-less domain represented as a RelabelType
(not CoerceToDomain) and thus the fix for [1] (ae7b1dd59) doesn't cover
this
case.

[1]
https://postgr.es/m/PH0PR21MB132823A46AA36F0685B7A29AD8BD9@PH0PR21MB1328.namprd21.prod.outlook.com

> On Fri, Apr 14, 2023 at 07:00:01PM +0000, PG Bug reporting form wrote:
>
> The following modified excerpt from regress/sql/domain.sql:
> create type comptype as (cf1 int, cf2 int);
> create domain dcomptype as comptype;
>
> create table dcomptable (f1 dcomptype[]);
> insert into dcomptable values (null);
> update dcomptable set f1[1].cf2 = 5;
>
> causes a server crash with the following stack trace:
> [...]
> Not reproduced on REL_11_STABLE, but reproduced on REL_12_STABLE .. master
> since 04fe805a1 made a constraint-less domain represented as a RelabelType
> (not CoerceToDomain) and thus the fix for [1] (ae7b1dd59) doesn't cover
> this
> case.

Looks like it could be fixed in the same way as in ae7b1dd59 ?

diff --git a/src/backend/executor/execExpr.c b/src/backend/executor/execExpr.c
index 4c6700de04..06fbf19423 100644
--- a/src/backend/executor/execExpr.c
+++ b/src/backend/executor/execExpr.c
@@ -3253,6 +3253,12 @@ isAssignmentIndirectionExpr(Expr *expr)

                return isAssignmentIndirectionExpr(cd->arg);
        }
+       else if (IsA(expr, RelabelType))
+       {
+               RelabelType *rt = (RelabelType *) expr;
+
+               return isAssignmentIndirectionExpr(rt->arg);
+       }
        return false;
 }

Dmitry Dolgov <9erthalion6@gmail.com> writes:
>> On Fri, Apr 14, 2023 at 07:00:01PM +0000, PG Bug reporting form wrote:
>> The following modified excerpt from regress/sql/domain.sql:
>> ...
>> causes a server crash with the following stack trace:
>> [...]
>> Not reproduced on REL_11_STABLE, but reproduced on REL_12_STABLE .. master
>> since 04fe805a1 made a constraint-less domain represented as a RelabelType
>> (not CoerceToDomain) and thus the fix for [1] (ae7b1dd59) doesn't cover
>> this case.

> Looks like it could be fixed in the same way as in ae7b1dd59 ?

Agreed, that seems like the obvious fix.  Thanks for the report,
and for the investigation!

            regards, tom lane