Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPfNv-000w8V-0G for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2026 11:46:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPfNs-007Nfl-30 for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2026 11:46:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPfNs-007Nfb-1X for pgsql-hackers@lists.postgresql.org; Wed, 20 May 2026 11:46:45 +0000 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wPfNq-00000000Trx-1j0D for pgsql-hackers@postgresql.org; Wed, 20 May 2026 11:46:44 +0000 Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-7de431da8fbso4276901a34.1 for ; Wed, 20 May 2026 04:46:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779277602; cv=none; d=google.com; s=arc-20240605; b=lUW6lPijb6RmsMMmKocFm8pqGIptuE8/5mWTjaWR/kibLGe7bRQauibLMw7P5gEEQQ LwhVx44ITlNj6RZmC7tRnlpXNnxS8eWXh8JPWCZ3JIlCcgJTaK0jigeg2EBSeBNuvx3U Nrw/sQsv32LRYNrdkZGpZcaUT3JcadoEo+iPe3liuB0aSyOCV6IjAWyOujVckLPGoouJ NH1yR4dBvj7+gygeWrNqixNjuj/H/5WIxU5le4TOrA3kd8F/ZdLYD6k8SkgIcCI7DcSb pXoEkIhLTsn2jYT38fHVk592eAKoYzKF3YsIQA31gyxtqjoeQ5QjPSAv79Nj7gwnezIe NrRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=j3sF4FBsWjrj4J07pZPMIBufRcvFOhNzHwKqAb7nYWY=; fh=vrnrv0MZtEyRKrxsXK1EnJaJMI7yXKyeZoZMiMAG61c=; b=l1BIDUrPJmjYQZF24DcVm2D7hP/w0kGbTklZ6NB59GNJFRXwsgTGZecaGEQMV2NSYn cADSIscfA6orElfFafFwd8yjC9Ao1V6hjNuWct2MUG4JXfKvYuD8TQD60MbvDC21Xbix g+90tVUpD1XpJQVFWd5e0g2kxx2YOytx+MAQwVxSF6/WLU54vuccZYv69GyBlmaPzI4M r5x46ITD4JQKBQPQtmSOlB8QS9Y/DtqaHQnVB3z0GUUHaEUDgHx788dNkdXjV39tK5EZ 1C9pLHOGPvBvzNcYFkUUulbzTJGIwHiJz2JxxsEID4FobW8T/WVcOqS4OMtx/WdXDBFl CUKw==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779277602; x=1779882402; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=j3sF4FBsWjrj4J07pZPMIBufRcvFOhNzHwKqAb7nYWY=; b=Y4Nz8BqdvUx/QCuM46m8zqZh4Ua+thWsFFmLziiX0sOPwfiNkra5EP8pBuLB5a9/z2 CcbMkecyPyIuK2Lu7b3iWRS4te2G16fke6bmo3nGwpo1QCFHFf0oucQYihr6xuMBXlWk vgG5LZq09kJG8DSadqACmJ9ltQ+tUHjxprGR2edO0B8L1o4V+MgbnRUB8Hii5/Eday4k mCiZPewQ872JtGbBgd+Mrtw96fSgnmEvVuW7c3T8FgI0psnlEePQf8wW0nQ6L4Rstspl ohjD+eYS61ebrYVEqOh0gxTUnByFrnGWWIqB5opHXOGkE+nwgU+tbyAD9H5Ogb7dqAl1 /8cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779277602; x=1779882402; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=j3sF4FBsWjrj4J07pZPMIBufRcvFOhNzHwKqAb7nYWY=; b=bAt0K3QTa9RStiWqJke1fb2fZmM+mdoREgXf3NOdQdN6cMo3KVwHFCqjdrdgv2qM8T FPFYGeOL9PCI7rOFmNIqaJvIBl3ZxfA6OjVqlVHLuSw1xwwpoX+j7bIVbUZpcHQ3d5Jj LzZOJTT7hfWPuLrya/EMWV+LUWhJdfFRQOkewBRonAkNT7he5Juq7ZX0NPi8FQVRmIGa BznIt0QEsDF9uncnHeF9kNyQWYam/zoUrWUgpDfFb9HTZsUPXLQZ+0qiuNmjnwZnVS4+ NSakaep1n3tExzDS4o+gM8Sn3fWoTSX0YQ6+6yqwPMEXgol155heCd0S1axozcEeZBxF ItIA== X-Forwarded-Encrypted: i=1; AFNElJ+e5hXOmJA0ToTG1PCfruEbNqLYDQWJyKwKfkY0GvnJNL1YIs60dWCtWCZaX0wj/cGZbIXevJcBskZjHWPW@postgresql.org X-Gm-Message-State: AOJu0YyUlbrngu9RwctTce6kL7TP+MhWSzxCSg+v1j5pmHoegYKkjE5q KfDjgB1+Ez/ErsJqm3XFRXxKvyYQejBk6+cspUiY7m7lFUFDX9j0YKmycloywI7zs5EBqqEnz46 xnz2J46NoAr9j6chTF9cpm7jOeIAt9wQ= X-Gm-Gg: Acq92OFw0DJaeru++ciNBOvZD0wWkPmdgyyda+5AQComzZX5KnZBhnspqW+7ughF1bF Y1tsq0Wqmx9gUecZqHnh2I5Nl2BfQZRp2LPZOvx6EyTh844WBzRFQAS4f334AEyjrYtNxSSSiWZ B4PKep0buPfU8vrv2amQz8RibD5zj7IDjQHiVUa5t2y+WnJPYjWRB6C1W7b78GPB3EVqpdXE0Kv zB8JZPLcVhu20+/0BHyjEIdXHe1y93Y7QUhOP3ErmMlabC+V2GCVCtpr0L0r5HAuZalBxWEE7F4 ukrN4Ai82zA8R/aYQCzSmrj3yqrWKtf4UGF5UPY5qdOmPCt/3PvxHqQGlPcDLhtJelIBkeyqlXG lo/6hAYSdFoZjB+SJ6bSHFKIFWERuNhTAHdd0zqdP X-Received: by 2002:a05:6820:221e:b0:69b:8c27:8a2 with SMTP id 006d021491bc7-69c93fa617dmr13710164eaf.0.1779277602448; Wed, 20 May 2026 04:46:42 -0700 (PDT) MIME-Version: 1.0 References: <4df20e70-a083-4334-9548-5f8b9025847c@postgrespro.ru> <4B04275C-E044-4EEE-BE64-6FEEE73DCBB0@gmail.com> <09307DC2-64A1-4D6A-9EAF-9A86A173A7FC@gmail.com> <8204A871-4650-4B3F-8260-8D5FD40908B3@gmail.com> <4AEA11EB-0439-401B-996E-F1835F510E8D@gmail.com> In-Reply-To: <4AEA11EB-0439-401B-996E-F1835F510E8D@gmail.com> From: Alexander Korotkov Date: Wed, 20 May 2026 14:46:30 +0300 X-Gm-Features: AVHnY4L_jjgBoXaNhLPk5VSLb02xKW1Ltig7_lq4QnW3_hb6wk9PWYtKpW6B5f8 Message-ID: Subject: Re: Fix SPLIT PARTITION bound-overlap bug and other improvements To: Chao Li Cc: Dmitry Koval , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, May 20, 2026 at 9:29=E2=80=AFAM Chao Li wr= ote: > > On May 20, 2026, at 14:19, Alexander Korotkov wr= ote: > > > > Hi, Chao! > > > > On Wed, May 20, 2026 at 2:37=E2=80=AFAM Chao Li wrote: > >>> On May 19, 2026, at 19:00, Alexander Korotkov = wrote: > >>> On Tue, May 19, 2026 at 5:50=E2=80=AFAM Chao Li wrote: > >>>>> On May 18, 2026, at 20:04, Alexander Korotkov wrote: > >>>>> > >>>>> On Mon, May 18, 2026 at 2:57=E2=80=AFPM Chao Li wrote: > >>>>>>> = > >>>>>> > >>>>>> v3-0001 through v3-0003 look good to me. > >>>>>> > >>>>>> For v3-0004, I have a suspicion, but it's late here and my brain i= s getting slow, so I would like to study it more tomorrow. > >>>>> > >>>>> Sure, take your time. > >>>>> > >>>>> ------ > >>>>> Regards, > >>>>> Alexander Korotkov > >>>>> Supabase > >>>> > >>>> My suspicion was that check_split_partition_not_same_bound() now has= two paths. The RANGE path honors collation, while the LIST path does not. = So I spent some time creating a test that uses a case-insensitive collation= : > >>>> ``` > >>>> evantest=3D# create collation case_insensitive (provider=3Dicu, loca= le=3D'und-u-ks-level2', deterministic =3D false); > >>>> CREATE COLLATION > >>>> evantest=3D# create table t (b text collate case_insensitive) partit= ion by list (b); > >>>> CREATE TABLE > >>>> evantest=3D# create table tp_ab partition of t for values in ('a', '= b'); > >>>> CREATE TABLE > >>>> evantest=3D# alter table t split partition tp_ab into > >>>> evantest-# (partition tp_a for values in ('a', 'A'), > >>>> evantest(# partition tp_default default); > >>>> ERROR: cannot split partition "tp_ab" only to add a DEFAULT partiti= on > >>>> LINE 2: (partition tp_a for values in ('a', 'A'), > >>>> ^ > >>>> DETAIL: The non-DEFAULT partition would keep the same partition bou= nd. > >>>> HINT: Use CREATE TABLE ... PARTITION OF ... DEFAULT to add a DEFAUL= T partition. > >>>> ``` > >>>> > >>>> In this test, the split partition=E2=80=99s bound is ('a', 'b'), and= the new partition=E2=80=99s bound is ('a', 'A'). Their list lengths are bo= th 2, but the two bounds are actually different, because 'a' and 'A' are co= nsidered equal by the collation. > >>>> > >>>> So, in the LIST path, since check_partition_bounds_for_split_list() = has already ensured that the new partition=E2=80=99s bound is contained wit= hin the split partition=E2=80=99s bound, we need to check the reverse direc= tion as well. Whether the split partition=E2=80=99s bound is also contained= in the new partition=E2=80=99s bound. If yes, the two bounds are identical= . > >>>> > >>>> See the attached v4 for my changes for 0004. 0001-0003 are unchanged= . Since 0001 and 0003 are independent of 0004, maybe they can be pushed fir= st. > >>> > >>> I've pushed 0001-0003. > >> > >> Thanks for pushing them. > >> > >>> Thank you for discovering the collation issue > >>> in 0004. Note that original approach of using > >>> partition_bounds_equal() can't handle different collations too (as it > >>> internally uses datumIsEqual()). > >> > >> Yes, I realized that while reviewing v3. That=E2=80=99s reason I didn= =E2=80=99t get back v2 and only worked again based on v3. > >> > >>> I've revised the remaining patch: > >>> made function header comment a bit more detailed > >> > >> This part looks good to me. > >> > >>> and added additional > >>> regression tests. Please, check. > >>> > >> > >> But I don=E2=80=99t see any change for regression test between v4 and = v5. Maybe you forgot to save your changes? > > > > Sorry, I just mess up, no changes in tests. > > I'm going to push this if no objection. > > > > No worries. Then v5 looks good to me. Thank you, pushed. ------ Regards, Alexander Korotkov Supabase