Assertion failure when ATTACH partition followed by CREATE PARTITION.

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

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