Horton

Thread

Commits

  1. Fix confusion about event trigger vs. plain function in plpgsql.

  1. BUG #16266: Server crash on SELECT event_trigger-returning function

    The Post Office <noreply@postgresql.org> — 2020-02-19T08:00:01Z

    The following bug has been logged on the website:

Bug reference:      16266
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 12.2
Operating system:   Ubuntu 18.04
Description:        

The following query:
CREATE OR REPLACE FUNCTION et() RETURNS event_trigger
LANGUAGE plpgsql AS $$
BEGIN
END;
$$;
SELECT et();

leads to a server crash with the following stack trace:
Core was generated by `postgres: law regression [local] SELECT              
                        '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005588f3fd816a in datumTransfer (value=0,
typByVal=typByVal@entry=false, typLen=typLen@entry=-1) at datum.c:194
194             if (!typByVal && typLen == -1 &&
(gdb) bt
#0  0x00005588f3fd816a in datumTransfer (value=0,
typByVal=typByVal@entry=false, typLen=typLen@entry=-1) at datum.c:194
#1  0x00005588f3e57505 in SPI_datumTransfer (value=<optimized out>,
typByVal=typByVal@entry=false, 
    typLen=typLen@entry=-1) at spi.c:1147
#2  0x00007fc5c7f7a6d6 in plpgsql_exec_function
(func=func@entry=0x5588f5711e10, fcinfo=fcinfo@entry=0x5588f57b0dd0, 
    simple_eval_estate=simple_eval_estate@entry=0x0,
atomic=atomic@entry=true) at pl_exec.c:651
#3  0x00007fc5c7f6d159 in plpgsql_call_handler (fcinfo=0x5588f57b0dd0) at
pl_handler.c:267
#4  0x00005588f3e189f5 in ExecInterpExpr (state=0x5588f57b0ce8,
econtext=0x5588f57b09d8, isnull=0x7ffcb32c30f7)
    at execExprInterp.c:625
#5  0x00005588f3e159f9 in ExecInterpExprStillValid (state=0x5588f57b0ce8,
econtext=0x5588f57b09d8, 
    isNull=0x7ffcb32c30f7) at execExprInterp.c:1778
#6  0x00005588f3e493f2 in ExecEvalExprSwitchContext (isNull=0x7ffcb32c30f7,
econtext=0x5588f57b09d8, 
    state=0x5588f57b0ce8) at ../../../src/include/executor/executor.h:307
#7  ExecProject (projInfo=0x5588f57b0ce0) at
../../../src/include/executor/executor.h:341
#8  ExecResult (pstate=<optimized out>) at nodeResult.c:136
#9  0x00005588f3e23de5 in ExecProcNodeFirst (node=0x5588f57b08c0) at
execProcnode.c:445
#10 0x00005588f3e1c712 in ExecProcNode (node=0x5588f57b08c0) at
../../../src/include/executor/executor.h:239
#11 ExecutePlan (estate=estate@entry=0x5588f57b0668,
planstate=0x5588f57b08c0, use_parallel_mode=<optimized out>, 
    operation=operation@entry=CMD_SELECT, sendTuples=sendTuples@entry=true,
numberTuples=numberTuples@entry=0, 
    direction=ForwardScanDirection, dest=0x5588f57bae38, execute_once=true)
at execMain.c:1646
#12 0x00005588f3e1d2f9 in standard_ExecutorRun (queryDesc=0x5588f57060a8,
direction=ForwardScanDirection, count=0, 
    execute_once=<optimized out>) at execMain.c:364
#13 0x00005588f3e1d3b8 in ExecutorRun
(queryDesc=queryDesc@entry=0x5588f57060a8, 
    direction=direction@entry=ForwardScanDirection, count=count@entry=0,
execute_once=<optimized out>)
    at execMain.c:308
#14 0x00005588f3f9ebbe in PortalRunSelect
(portal=portal@entry=0x5588f574c688, forward=forward@entry=true, count=0, 
    count@entry=9223372036854775807, dest=dest@entry=0x5588f57bae38) at
pquery.c:929
#15 0x00005588f3fa0264 in PortalRun (portal=portal@entry=0x5588f574c688,
count=count@entry=9223372036854775807, 
    isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true,
dest=dest@entry=0x5588f57bae38, 
    altdest=altdest@entry=0x5588f57bae38, completionTag=0x7ffcb32c33f0 "")
at pquery.c:770
#16 0x00005588f3f9c5a9 in exec_simple_query
(query_string=query_string@entry=0x5588f56e53d8 "SELECT et();")
    at postgres.c:1215
#17 0x00005588f3f9e588 in PostgresMain (argc=<optimized out>,
argv=argv@entry=0x5588f5710788, dbname=<optimized out>, 
    username=<optimized out>) at postgres.c:4247
#18 0x00005588f3f107bf in BackendRun (port=port@entry=0x5588f5708e60) at
postmaster.c:4437
#19 0x00005588f3f13a85 in BackendStartup (port=port@entry=0x5588f5708e60) at
postmaster.c:4128
#20 0x00005588f3f13d9c in ServerLoop () at postmaster.c:1704
#21 0x00005588f3f1518d in PostmasterMain (argc=3, argv=<optimized out>) at
postmaster.c:1377
#22 0x00005588f3e705cd in main (argc=3, argv=0x5588f56dfa30) at main.c:228

Reproduced on REL_11_0..master.

  2. Re: BUG #16266: Server crash on SELECT event_trigger-returning function

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-02-19T16:05:05Z

    PG Bug reporting form <noreply@postgresql.org> writes:
> The following query:
> CREATE OR REPLACE FUNCTION et() RETURNS event_trigger
> LANGUAGE plpgsql AS $$
> BEGIN
> END;
> $$;
> SELECT et();

> leads to a server crash with the following stack trace:

Yeah.  If you didn't just validate the function, it does the expected
thing:

regression=# SELECT et();
ERROR:  trigger functions can only be called as triggers
CONTEXT:  compilation of PL/pgSQL function "et" near line 1

I think perhaps the problem is that compute_function_hashkey hasn't
been fixed to deal with event triggers sanely.  They need to not
have the same hash keys as ordinary function calls.

			regards, tom lane