Thread: Assertion failure when ATTACH partition followed by CREATE PARTITION.
Hi, Assertion added in commits 6b2c4e59d016 is failing with following test: CREATE TABLE sales ( prod_id int, prod_quantity int, sold_month date ) PARTITION BY RANGE(sold_month); CREATE TABLE public.sales_p1 PARTITION OF public.sales FOR VALUES FROM (MINVALUE) TO ('2019-02-15'); CREATE TABLE sales_p2(like sales including all); ALTER TABLE sales ATTACH PARTITION sales_p2 FOR VALUES FROM ('2019-02-15') TO ('2019-03-15'); CREATE TABLE fail PARTITION OF public.sales FOR VALUES FROM ('2019-01-15') TO ('2019-02-15'); Here is the backtrace: (gdb) bt #0 0x00007fa373333277 in raise () from /lib64/libc.so.6 #1 0x00007fa373334968 in abort () from /lib64/libc.so.6 #2 0x0000000000abecdc in ExceptionalCondition (conditionName=0xc5de6d "cmpval >= 0", errorType=0xc5cf03 "FailedAssertion", fileName=0xc5d03e "partbounds.c", lineNumber=3092) at assert.c:69 #3 0x000000000086189c in check_new_partition_bound (relname=0x7fff225f5ef0 "fail", parent=0x7fa3744868a0, spec=0x2e98888, pstate=0x2e905e8) at partbounds.c:3092 #4 0x00000000006b44dc in DefineRelation (stmt=0x2e83198, relkind=114 'r', ownerId=10, typaddress=0x0, queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.sales \nFOR VALUES FROM ('2019-01-15') TO ('2019-02-15');") at tablecmds.c:1011 #5 0x0000000000941430 in ProcessUtilitySlow (pstate=0x2e83080, pstmt=0x2dc19b8, queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.sales \nFOR VALUES FROM ('2019-01-15') TO ('2019-02-15');", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x2dc1aa8, qc=0x7fff225f67c0) at utility.c:1163 #6 0x000000000094123e in standard_ProcessUtility (pstmt=0x2dc19b8, queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.s ales \nFOR VALUES FROM ('2019-01-15') TO ('2019-02-15');", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x2dc1 aa8, qc=0x7fff225f67c0) at utility.c:1071 #7 0x0000000000940349 in ProcessUtility (pstmt=0x2dc19b8, queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.sales \nFO R VALUES FROM ('2019-01-15') TO ('2019-02-15');", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x2dc1aa8, qc=0 x7fff225f67c0) at utility.c:524 #8 0x000000000093f163 in PortalRunUtility (portal=0x2e22ab0, pstmt=0x2dc19b8, isTopLevel=true, setHoldSnapshot=false, dest=0x2dc1 aa8, qc=0x7fff225f67c0) at pquery.c:1159 #9 0x000000000093f380 in PortalRunMulti (portal=0x2e22ab0, isTopLevel=true, setHoldSnapshot=false, dest=0x2dc1aa8, altdest=0x2dc1 aa8, qc=0x7fff225f67c0) at pquery.c:1305 #10 0x000000000093e882 in PortalRun (portal=0x2e22ab0, count=9223372036854775807, isTopLevel=true, run_once=true, dest=0x2dc1aa8, altdest=0x2dc1aa8, qc=0x7fff225f67c0) at pquery.c:779 #11 0x00000000009389e8 in exec_simple_query (query_string=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.sales \nFOR VALUES FROM ('2019-01-15') TO ('2019-02-15');") at postgres.c:1239 Regards, Amul Sul
Hi, On Mon, Oct 19, 2020 at 4:58 PM Amul Sul <sulamul@gmail.com> wrote: > > Hi, > > Assertion added in commits 6b2c4e59d016 is failing with following test: > > CREATE TABLE sales > ( > prod_id int, > prod_quantity int, > sold_month date > ) PARTITION BY RANGE(sold_month); > > CREATE TABLE public.sales_p1 PARTITION OF public.sales > FOR VALUES FROM (MINVALUE) TO ('2019-02-15'); > > CREATE TABLE sales_p2(like sales including all); > ALTER TABLE sales ATTACH PARTITION sales_p2 > FOR VALUES FROM ('2019-02-15') TO ('2019-03-15'); > > CREATE TABLE fail PARTITION OF public.sales > FOR VALUES FROM ('2019-01-15') TO ('2019-02-15'); > The reported issue has nothing to do with the ATTACH PARTITION stmt this can also be reproducible with the following CREATE stmts: CREATE TABLE sales ( prod_id int, prod_quantity int, sold_month date ) PARTITION BY RANGE(sold_month); CREATE TABLE sales_p1 PARTITION OF sales FOR VALUES FROM (MINVALUE) TO ('2019-02-15'); CREATE TABLE sales_p2 PARTITION OF sales FOR VALUES FROM ('2019-02-15') TO ('2019-03-15'); CREATE TABLE fail PARTITION OF sales FOR VALUES FROM ('2019-01-15') TO ('2019-02-15'); AFAICU, the assert assumption is not correct. In the attached patch, I have removed that assert and the related comment. Also, minor adjustments to the code fetching correct datum. Regards, Amul > > Here is the backtrace: > > (gdb) bt > #0 0x00007fa373333277 in raise () from /lib64/libc.so.6 > #1 0x00007fa373334968 in abort () from /lib64/libc.so.6 > #2 0x0000000000abecdc in ExceptionalCondition (conditionName=0xc5de6d > "cmpval >= 0", errorType=0xc5cf03 "FailedAssertion", fileName=0xc5d03e > "partbounds.c", lineNumber=3092) at assert.c:69 > #3 0x000000000086189c in check_new_partition_bound > (relname=0x7fff225f5ef0 "fail", parent=0x7fa3744868a0, spec=0x2e98888, > pstate=0x2e905e8) at partbounds.c:3092 > #4 0x00000000006b44dc in DefineRelation (stmt=0x2e83198, relkind=114 > 'r', ownerId=10, typaddress=0x0, queryString=0x2dc07c0 "CREATE TABLE > fail PARTITION OF public.sales \nFOR VALUES FROM ('2019-01-15') TO > ('2019-02-15');") at tablecmds.c:1011 > #5 0x0000000000941430 in ProcessUtilitySlow (pstate=0x2e83080, > pstmt=0x2dc19b8, queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF > public.sales \nFOR VALUES FROM ('2019-01-15') TO ('2019-02-15');", > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, > dest=0x2dc1aa8, qc=0x7fff225f67c0) at utility.c:1163 > #6 0x000000000094123e in standard_ProcessUtility (pstmt=0x2dc19b8, > queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.s ales > \nFOR VALUES FROM ('2019-01-15') TO ('2019-02-15');", > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, > dest=0x2dc1 aa8, qc=0x7fff225f67c0) at utility.c:1071 > #7 0x0000000000940349 in ProcessUtility (pstmt=0x2dc19b8, > queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.sales > \nFO R VALUES FROM ('2019-01-15') TO ('2019-02-15');", > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, > dest=0x2dc1aa8, qc=0 x7fff225f67c0) at utility.c:524 > #8 0x000000000093f163 in PortalRunUtility (portal=0x2e22ab0, > pstmt=0x2dc19b8, isTopLevel=true, setHoldSnapshot=false, dest=0x2dc1 > aa8, qc=0x7fff225f67c0) at pquery.c:1159 > #9 0x000000000093f380 in PortalRunMulti (portal=0x2e22ab0, > isTopLevel=true, setHoldSnapshot=false, dest=0x2dc1aa8, altdest=0x2dc1 > aa8, qc=0x7fff225f67c0) at pquery.c:1305 > #10 0x000000000093e882 in PortalRun (portal=0x2e22ab0, > count=9223372036854775807, isTopLevel=true, run_once=true, > dest=0x2dc1aa8, altdest=0x2dc1aa8, qc=0x7fff225f67c0) at pquery.c:779 > #11 0x00000000009389e8 in exec_simple_query (query_string=0x2dc07c0 > "CREATE TABLE fail PARTITION OF public.sales \nFOR VALUES FROM > ('2019-01-15') TO ('2019-02-15');") at postgres.c:1239 > > Regards, > Amul Sul
Attachment
Not sure if Tom saw this yet. On Tue, Oct 27, 2020 at 10:56:01AM +0530, Amul Sul wrote: > On Mon, Oct 19, 2020 at 4:58 PM Amul Sul <sulamul@gmail.com> wrote: > > > > Hi, > > > > Assertion added in commits 6b2c4e59d016 is failing with following test: > > > > CREATE TABLE sales > > ( > > prod_id int, > > prod_quantity int, > > sold_month date > > ) PARTITION BY RANGE(sold_month); > > > > CREATE TABLE public.sales_p1 PARTITION OF public.sales > > FOR VALUES FROM (MINVALUE) TO ('2019-02-15'); > > > > CREATE TABLE sales_p2(like sales including all); > > ALTER TABLE sales ATTACH PARTITION sales_p2 > > FOR VALUES FROM ('2019-02-15') TO ('2019-03-15'); > > > > CREATE TABLE fail PARTITION OF public.sales > > FOR VALUES FROM ('2019-01-15') TO ('2019-02-15'); > > The reported issue has nothing to do with the ATTACH PARTITION stmt this can > also be reproducible with the following CREATE stmts: > > CREATE TABLE sales > ( > prod_id int, > prod_quantity int, > sold_month date > ) PARTITION BY RANGE(sold_month); > > CREATE TABLE sales_p1 PARTITION OF sales > FOR VALUES FROM (MINVALUE) TO ('2019-02-15'); > > CREATE TABLE sales_p2 PARTITION OF sales > FOR VALUES FROM ('2019-02-15') TO ('2019-03-15'); > > CREATE TABLE fail PARTITION OF sales > FOR VALUES FROM ('2019-01-15') TO ('2019-02-15'); > > AFAICU, the assert assumption is not correct. In the attached patch, I have > removed that assert and the related comment. Also, minor adjustments to the > code fetching correct datum. > > Regards, > Amul > > > > > Here is the backtrace: > > > > (gdb) bt > > #0 0x00007fa373333277 in raise () from /lib64/libc.so.6 > > #1 0x00007fa373334968 in abort () from /lib64/libc.so.6 > > #2 0x0000000000abecdc in ExceptionalCondition (conditionName=0xc5de6d > > "cmpval >= 0", errorType=0xc5cf03 "FailedAssertion", fileName=0xc5d03e > > "partbounds.c", lineNumber=3092) at assert.c:69 > > #3 0x000000000086189c in check_new_partition_bound > > (relname=0x7fff225f5ef0 "fail", parent=0x7fa3744868a0, spec=0x2e98888, > > pstate=0x2e905e8) at partbounds.c:3092 > > #4 0x00000000006b44dc in DefineRelation (stmt=0x2e83198, relkind=114 > > 'r', ownerId=10, typaddress=0x0, queryString=0x2dc07c0 "CREATE TABLE > > fail PARTITION OF public.sales \nFOR VALUES FROM ('2019-01-15') TO > > ('2019-02-15');") at tablecmds.c:1011 > > #5 0x0000000000941430 in ProcessUtilitySlow (pstate=0x2e83080, > > pstmt=0x2dc19b8, queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF > > public.sales \nFOR VALUES FROM ('2019-01-15') TO ('2019-02-15');", > > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, > > dest=0x2dc1aa8, qc=0x7fff225f67c0) at utility.c:1163 > > #6 0x000000000094123e in standard_ProcessUtility (pstmt=0x2dc19b8, > > queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.s ales > > \nFOR VALUES FROM ('2019-01-15') TO ('2019-02-15');", > > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, > > dest=0x2dc1 aa8, qc=0x7fff225f67c0) at utility.c:1071 > > #7 0x0000000000940349 in ProcessUtility (pstmt=0x2dc19b8, > > queryString=0x2dc07c0 "CREATE TABLE fail PARTITION OF public.sales > > \nFO R VALUES FROM ('2019-01-15') TO ('2019-02-15');", > > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, > > dest=0x2dc1aa8, qc=0 x7fff225f67c0) at utility.c:524 > > #8 0x000000000093f163 in PortalRunUtility (portal=0x2e22ab0, > > pstmt=0x2dc19b8, isTopLevel=true, setHoldSnapshot=false, dest=0x2dc1 > > aa8, qc=0x7fff225f67c0) at pquery.c:1159 > > #9 0x000000000093f380 in PortalRunMulti (portal=0x2e22ab0, > > isTopLevel=true, setHoldSnapshot=false, dest=0x2dc1aa8, altdest=0x2dc1 > > aa8, qc=0x7fff225f67c0) at pquery.c:1305 > > #10 0x000000000093e882 in PortalRun (portal=0x2e22ab0, > > count=9223372036854775807, isTopLevel=true, run_once=true, > > dest=0x2dc1aa8, altdest=0x2dc1aa8, qc=0x7fff225f67c0) at pquery.c:779 > > #11 0x00000000009389e8 in exec_simple_query (query_string=0x2dc07c0 > > "CREATE TABLE fail PARTITION OF public.sales \nFOR VALUES FROM > > ('2019-01-15') TO ('2019-02-15');") at postgres.c:1239 > > > > Regards, > > Amul Sul -- Justin Pryzby System Administrator Telsasoft +1-952-707-8581
Justin Pryzby <pryzby@telsasoft.com> writes: > Not sure if Tom saw this yet. Indeed, I'd not been paying attention. Fix looks good, pushed. regards, tom lane