Thread

Commits

Fix unsafe memory management in CloneRowTriggersToPartition().
- eaf0292c3ba7 12.0 landed
- 601084eb1aa8 11.4 landed

BUG #15828: Server crashes inside CloneRowTriggersToPartition

The Post Office <noreply@postgresql.org> — 2019-05-31T18:50:37Z

The following bug has been logged on the website:

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

When running in parallel two queries (modified excerpts from
src/test/regress/ join.sql and update.sql):
--
SELECT count(*) FROM
  tenk1 a JOIN tenk1 b ON a.unique1 = b.unique2
  LEFT JOIN tenk1 c ON c.thousand = a.thousand;
--
DROP TABLE IF EXISTS range_parted CASCADE;
DROP FUNCTION IF EXISTS trigfunc CASCADE;

CREATE TABLE range_parted (b bigint) PARTITION BY RANGE (b);
CREATE TABLE part_1_10 PARTITION OF range_parted FOR VALUES FROM (1) TO
(10);

CREATE FUNCTION trigfunc() RETURNS TRIGGER LANGUAGE plpgsql AS 'begin return
null; end;';

CREATE TRIGGER trigger1  AFTER INSERT ON range_parted FOR EACH STATEMENT
EXECUTE PROCEDURE trigfunc();

CREATE TRIGGER trigger2  AFTER INSERT ON range_parted FOR EACH STATEMENT
EXECUTE PROCEDURE trigfunc();
DROP TRIGGER trigger2 ON range_parted;

INSERT INTO range_parted VALUES (0);
SELECT pg_sleep(0.05);
CREATE TABLE part_def PARTITION OF range_parted DEFAULT;
--
I get a crash with the following core dump:

Core was generated by `postgres: law regression [local] CREATE TABLE        
                        '.
Program terminated with signal SIGBUS, Bus error.
#0  0x000055594492427f in GetMemoryChunkContext (pointer=0x5559466ff0a0)
    at ../../../../src/include/utils/memutils.h:129
129             AssertArg(MemoryContextIsValid(context));
(gdb) bt
#0  0x000055594492427f in GetMemoryChunkContext (pointer=0x5559466ff0a0)
    at ../../../../src/include/utils/memutils.h:129
#1  pfree (pointer=0x5559466ff0a0) at mcxt.c:1033
#2  0x00005559444dedc4 in btendscan (scan=<optimized out>) at nbtree.c:479
#3  0x00005559444d2eaf in index_endscan (scan=0x5559466fc9f0) at
indexam.c:328
#4  0x00005559444d25ed in systable_endscan
(sysscan=sysscan@entry=0x55594663ccc0) at genam.c:535
#5  0x0000555944604716 in CloneRowTriggersToPartition
(parent=parent@entry=0x7fcb7cbb97b8, 
    partition=partition@entry=0x7fcb7cbbd138) at tablecmds.c:15885
#6  0x00005559446155b4 in DefineRelation (stmt=stmt@entry=0x5559466e1050,
relkind=<optimized out>, 
    relkind@entry=114 'r', ownerId=10, ownerId@entry=0,
typaddress=typaddress@entry=0x0, 
    queryString=queryString@entry=0x55594661c788 "CREATE TABLE part_def
PARTITION OF range_parted DEFAULT;")
    at tablecmds.c:1090
#7  0x00005559447cf575 in ProcessUtilitySlow
(pstate=pstate@entry=0x5559466e0f38, pstmt=pstmt@entry=0x55594661d718, 
    queryString=queryString@entry=0x55594661c788 "CREATE TABLE part_def
PARTITION OF range_parted DEFAULT;", 
    context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=params@entry=0x0,
queryEnv=queryEnv@entry=0x0, 
    dest=0x55594661d810, completionTag=0x7ffe17b7bb00 "") at
utility.c:1014
#8  0x00005559447cf329 in standard_ProcessUtility (pstmt=0x55594661d718, 
    queryString=0x55594661c788 "CREATE TABLE part_def PARTITION OF
range_parted DEFAULT;", 
    context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0,
dest=0x55594661d810, completionTag=0x7ffe17b7bb00 "")
    at utility.c:927
#9  0x00005559447cf3d7 in ProcessUtility (pstmt=pstmt@entry=0x55594661d718,
queryString=<optimized out>, 
    context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=<optimized out>,
queryEnv=<optimized out>, 
    dest=dest@entry=0x55594661d810, completionTag=0x7ffe17b7bb00 "") at
utility.c:360
#10 0x00005559447cb87e in PortalRunUtility
(portal=portal@entry=0x555946683b58, pstmt=pstmt@entry=0x55594661d718, 
    isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x55594661d810,

    completionTag=completionTag@entry=0x7ffe17b7bb00 "") at pquery.c:1175
#11 0x00005559447cc4cd in PortalRunMulti
(portal=portal@entry=0x555946683b58, isTopLevel=isTopLevel@entry=true, 
    setHoldSnapshot=setHoldSnapshot@entry=false,
dest=dest@entry=0x55594661d810, altdest=altdest@entry=0x55594661d810, 
    completionTag=completionTag@entry=0x7ffe17b7bb00 "") at pquery.c:1321
#12 0x00005559447cd23d in PortalRun (portal=portal@entry=0x555946683b58,
count=count@entry=9223372036854775807, 
    isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true,
dest=dest@entry=0x55594661d810, 
    altdest=altdest@entry=0x55594661d810, completionTag=0x7ffe17b7bb00 "")
at pquery.c:796
#13 0x00005559447c94ed in exec_simple_query (
    query_string=query_string@entry=0x55594661c788 "CREATE TABLE part_def
PARTITION OF range_parted DEFAULT;")
    at postgres.c:1215
#14 0x00005559447cb4bd in PostgresMain (argc=<optimized out>,
argv=argv@entry=0x555946647dc0, dbname=<optimized out>, 
    username=<optimized out>) at postgres.c:4249
#15 0x000055594473dcaa in BackendRun (port=port@entry=0x555946640e80) at
postmaster.c:4431
#16 0x0000555944740ece in BackendStartup (port=port@entry=0x555946640e80) at
postmaster.c:4122
#17 0x00005559447411e5 in ServerLoop () at postmaster.c:1704
#18 0x00005559447425f2 in PostmasterMain (argc=8, argv=<optimized out>) at
postmaster.c:1377
#19 0x000055594469e26e in main (argc=8, argv=0x555946616b70) at main.c:228

Re: BUG #15828: Server crashes inside CloneRowTriggersToPartition

Alexander Law <exclusion@gmail.com> — 2019-05-31T19:01:17Z

> The following bug has been logged on the website:
>
> Bug reference:      15828
> Logged by:          Alexander Lakhin
> Email address:      exclusion@gmail.com
> PostgreSQL version: 12beta1
> Operating system:   Ubuntu 18.04
> Description:        
>
> When running in parallel two queries (modified excerpts from
> src/test/regress/ join.sql and update.sql):
The patch to reproduce the crash on master is attached,
With the patch applied, you can execute
'EXTRA_TESTS="--schedule=test_schedule" make check' and get:
...
test stats                        ... ok          642 ms
parallel group (2 tests):  join1 update1
     join1                        ... FAILED       43 ms
     update1                      ... FAILED (test process exited with
exit code 2)      530 ms
============== shutting down postmaster               ==============
...

Best regards,
Alexander

Re: BUG #15828: Server crashes inside CloneRowTriggersToPartition

Tom Lane <tgl@sss.pgh.pa.us> — 2019-06-03T20:38:30Z

Alexander Lakhin <exclusion@gmail.com> writes:
>> When running in parallel two queries (modified excerpts from
>> src/test/regress/ join.sql and update.sql):

> The patch to reproduce the crash on master is attached,

Thanks for the test case.  It's surprising though that we don't see
this fail out-of-the-box.  It's not okay to reset the context that
a systable scan is using ...

			regards, tom lane