Thread

Commits

  1. Fix assignment to array of domain over composite, redux.

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

    The Post Office <noreply@postgresql.org> — 2023-04-14T19:00:01Z

    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
    
    
  2. Re: BUG #17897: Crash on assignment to array of constraint-less domain over composite type

    Dmitry Dolgov <9erthalion6@gmail.com> — 2023-04-15T15:17:09Z

    > 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;
     }
    
    
    
    
  3. Re: BUG #17897: Crash on assignment to array of constraint-less domain over composite type

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-04-15T15:26:04Z

    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