Hi,

On Mon, Oct 19, 2020 at 4:58 PM Amul Sul <sula...@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
From 983c950ec26ef88127c1c349f6fa34f754a239f0 Mon Sep 17 00:00:00 2001
From: Amul Sul <amul.sul@enterprisedb.com>
Date: Tue, 27 Oct 2020 00:45:35 -0400
Subject: [PATCH] Fix assertion.

---
 src/backend/partitioning/partbounds.c      | 10 +++-------
 src/test/regress/expected/create_table.out |  4 ++++
 src/test/regress/sql/create_table.sql      |  1 +
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/backend/partitioning/partbounds.c b/src/backend/partitioning/partbounds.c
index 66c42b58986..c8a42b4970d 100644
--- a/src/backend/partitioning/partbounds.c
+++ b/src/backend/partitioning/partbounds.c
@@ -3061,7 +3061,7 @@ check_new_partition_bound(char *relname, Relation parent,
 								 * datums list.
 								 */
 								PartitionRangeDatum *datum =
-								list_nth(spec->upperdatums, -cmpval - 1);
+								list_nth(spec->upperdatums, Abs(cmpval) - 1);
 
 								/*
 								 * The new partition overlaps with the
@@ -3084,14 +3084,10 @@ check_new_partition_bound(char *relname, Relation parent,
 
 						/*
 						 * Fetch the problematic key from the lower datums
-						 * list.  Given the way partition_range_bsearch()
-						 * works, the new lower bound is certainly >= the
-						 * bound at offset.  If the bound matches exactly, we
-						 * flag the 1st key.
+						 * list.
 						 */
-						Assert(cmpval >= 0);
 						datum = cmpval == 0 ? linitial(spec->lowerdatums) :
-							list_nth(spec->lowerdatums, cmpval - 1);
+							list_nth(spec->lowerdatums, Abs(cmpval) - 1);
 						overlap = true;
 						overlap_location = datum->location;
 						with = boundinfo->indexes[offset + 1];
diff --git a/src/test/regress/expected/create_table.out b/src/test/regress/expected/create_table.out
index 1fc266dd65c..ed8c01b8dec 100644
--- a/src/test/regress/expected/create_table.out
+++ b/src/test/regress/expected/create_table.out
@@ -856,6 +856,10 @@ ERROR:  partition "fail_part" would overlap partition "part0"
 LINE 1: ..._part PARTITION OF range_parted2 FOR VALUES FROM (minvalue) ...
                                                              ^
 CREATE TABLE part1 PARTITION OF range_parted2 FOR VALUES FROM (1) TO (10);
+CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (-1) TO (1);
+ERROR:  partition "fail_part" would overlap partition "part0"
+LINE 1: ..._part PARTITION OF range_parted2 FOR VALUES FROM (-1) TO (1)...
+                                                             ^
 CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (9) TO (maxvalue);
 ERROR:  partition "fail_part" would overlap partition "part1"
 LINE 1: ..._part PARTITION OF range_parted2 FOR VALUES FROM (9) TO (max...
diff --git a/src/test/regress/sql/create_table.sql b/src/test/regress/sql/create_table.sql
index cee822aa8b6..d257679ba68 100644
--- a/src/test/regress/sql/create_table.sql
+++ b/src/test/regress/sql/create_table.sql
@@ -687,6 +687,7 @@ CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (1) TO (1);
 CREATE TABLE part0 PARTITION OF range_parted2 FOR VALUES FROM (minvalue) TO (1);
 CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (minvalue) TO (2);
 CREATE TABLE part1 PARTITION OF range_parted2 FOR VALUES FROM (1) TO (10);
+CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (-1) TO (1);
 CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (9) TO (maxvalue);
 CREATE TABLE part2 PARTITION OF range_parted2 FOR VALUES FROM (20) TO (30);
 CREATE TABLE part3 PARTITION OF range_parted2 FOR VALUES FROM (30) TO (40);
-- 
2.18.0

Reply via email to