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 1wPaHK-000rSW-2e for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2026 06:19:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPaHG-006Jfg-2P for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2026 06:19:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPaHG-006JfX-15 for pgsql-hackers@lists.postgresql.org; Wed, 20 May 2026 06:19:35 +0000 Received: from mail-oo1-xc33.google.com ([2607:f8b0:4864:20::c33]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wPaHF-00000000VIt-150J for pgsql-hackers@postgresql.org; Wed, 20 May 2026 06:19:35 +0000 Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-69b8cdfcf50so2340947eaf.2 for ; Tue, 19 May 2026 23:19:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779257971; cv=none; d=google.com; s=arc-20240605; b=c7c0XZfmUS2bsZCePG7+FehQavwnuqnsnxh+JaG+bVlknbjAPTccioxROJQylnoLWl MsxnqZzVqLcxmPkcqDasIBvtVcrBCYU+Ih4Mn/ACyKM2yMe5a3l/2+UYPrLBTySKp78V gMB3Cg4sJ0plUTbrWp3R2+hlPla/KFyva+uWDCVWwi4XU9kpJbshO/rNXWatgOA4RFuH I3qdxtxs6RckoWl9AdiB22syZmVc/FJrENRVfNLHsEvt4nX0URoTMOZrJFYjgXMjkive 1BL68G1ReOe3NjebXX5WxZYanMXwJ9Sj7fp11gh6QKqlF2KKXT1Z5578pVXUuOSFOmC5 STZw== 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=ORno1jlp4dEt2yBQ63XCErdfcix9cIkn2b/lZX7Uaxg=; fh=mevKEXovzN300HoQX7pMi5CgePjm5pJ0Cz2VjpqywSw=; b=jva1GOrax4pWYIZt8BU61Zc1XyS6l5s1Hm4v1VEl8A2wkaIyS27qgyB05lQwkPxWOc HErWtBPqLATVJyZTbuJDGptn+iLHZJMJ5/OfBvJOEon9z+viBsng5DnSUh2H2tG68dM6 +ppzacSTnXleeDqefCYCpkxPN7FlhsbQgZlbxAzBT2T3kX1sp22ujAS2p6k4p2wTF6O1 7N7KnNO3QxV7KWSmIkmAqoh6bmNkLkRQkMltvOiqA+s5Ry/wEzsji9TfIGO1g6GSzLE0 6Bc2EEzqNBAux93F5cPlypuShZ7vUsJZx2OLW9/xM5uv4aXZ+uGxOD4JPXDMVnuv5sED J7nA==; 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=1779257971; x=1779862771; 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=ORno1jlp4dEt2yBQ63XCErdfcix9cIkn2b/lZX7Uaxg=; b=out6um5weV8a/D4byRmgdUoBgEn6i1912I26F7E3yBxTbKy9J+83I1O6HuwgyUr21K Cq1EaCgrI+Aogmx3dh9fF58q1dPfih5O4aJYMoDEx4OHBjuPrZbP2Pqjn6rZOhSMWPil 13l2izn4I5KMPIw0Fxg7Qly3NcvR+AQUxxuvvzpA6sTwMtl4xxXjLTACZNQBR+16BP8U 7GaRnFACaRGNdNl22zPZpELwLf9+H4nT2W0CFBp/bJrKj6d/0DPlHltUltXBGEgnQeXg U/YRN+eBYC6ntpT2rL5VixtAWBUNhryz/WPyiwslZH6N9TmFpN/HXriLrmmomOaLhRT9 TrZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779257971; x=1779862771; 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=ORno1jlp4dEt2yBQ63XCErdfcix9cIkn2b/lZX7Uaxg=; b=QM4EsznmsBKyiSFRgGaBiSVZ6+gf5MKymhExso+sM2SdmHqaeCk35L8wNFC7fim5Wk M+reDwtWY368Pk9VTA3DNpRNAcMdfNHQmr/RtX14eW+SYCemO6Bp6mAAIPUDgJcACkMY 6/6BJyG69ET9BEie+kU/beRB1cRUSI1Ez6bHE7E85pYv8JplGv+9qoR0aEHoZ+9gamZs NssKT9eCas4U92Dgcp6equIG8JqnTJsig2omeLgjExFJ9o4XfpC2oWvmLCteYRQi4JWn V/cC0qEtJZRV3AcBJ+M5fYEqW6uaNWwn27pj0+n5fwdnsbrdNS4cPE0AeKArfkCQbKNC Zscg== X-Forwarded-Encrypted: i=1; AFNElJ8KbsLy+YQDQWwA3D4uoDGDjoRmSSYG5UrDpbRYYzLgSHi9G+suDKuiVhg03e5v98FK8CAKnU/kDjUkOLSx@postgresql.org X-Gm-Message-State: AOJu0Yy78CRHLfVE2vvRdxxHPIG9DqASRgfOdOrDpndBwsk5VLYy/gjM lBcFSGFdhlTikdnuXidGgjZdfQO3czm1Bz02wu0LUxAZdVlIeDlJB/oor+2mo9UQ01IoVVwBWsR JptUxrYSUMA4TQa4vgALOWq8eVNTkyB/8YQMW66Ml7w== X-Gm-Gg: Acq92OEC7dvoVWE+79ZqCGgr894U3eclIy7gUFXvGTCAKAVdnYAvnq8iMqmXm4KWX0C 23PyCBet6QtGhZ/Q4XGHpOJ24KhzhMgCRwXOkgmr2bFon07MDNS9Qqxk53cmZ86EwLQHNTkU0AX DzqDBddIUZqU1gXnSQiajFednfiAnhAvgw/624k2kIC4yNSc8i2CsKpFN6WwuEfMQHj3v3huQWa 4mFJZiFHvU0ufAnkjKJeFquUPMmCbmNXz2w8OFRqe00qvWhoANWee6m5T7QuckO7Y5yI8EM5Juq fdwFAdEAxvfPNvBjz0f3eHQ+2pXAMPRKv1YWwKIE3ZkcoiZTQ4vYyxLztk5scB4NTrnZSsJRySN uB9logiRu3ZcoKXC7KpxzgtFUrLQHj+xxAcCWTLLW X-Received: by 2002:a05:6820:200c:b0:696:637e:4837 with SMTP id 006d021491bc7-69c9431af15mr14551209eaf.27.1779257970996; Tue, 19 May 2026 23:19:30 -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> In-Reply-To: <8204A871-4650-4B3F-8260-8D5FD40908B3@gmail.com> From: Alexander Korotkov Date: Wed, 20 May 2026 09:19:18 +0300 X-Gm-Features: AVHnY4IQc-wFUQu6WZuP5eCwCN2UjazOxICPj0xF9AeKofTYf2hVkRpWN-6GSc8 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 Hi, Chao! On Wed, May 20, 2026 at 2:37=E2=80=AFAM Chao Li wr= ote: > > On May 19, 2026, at 19:00, Alexander Korotkov wr= ote: > > 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 is = 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 t= wo 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, locale= =3D'und-u-ks-level2', deterministic =3D false); > >> CREATE COLLATION > >> evantest=3D# create table t (b text collate case_insensitive) partitio= n 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 partition > >> LINE 2: (partition tp_a for values in ('a', 'A'), > >> ^ > >> DETAIL: The non-DEFAULT partition would keep the same partition bound= . > >> HINT: Use CREATE TABLE ... PARTITION OF ... DEFAULT to add a DEFAULT = partition. > >> ``` > >> > >> In this test, the split partition=E2=80=99s bound is ('a', 'b'), and t= he new partition=E2=80=99s bound is ('a', 'A'). Their list lengths are both= 2, but the two bounds are actually different, because 'a' and 'A' are cons= idered equal by the collation. > >> > >> So, in the LIST path, since check_partition_bounds_for_split_list() ha= s already ensured that the new partition=E2=80=99s bound is contained withi= n the split partition=E2=80=99s bound, we need to check the reverse directi= on as well. Whether the split partition=E2=80=99s bound is also contained i= n 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 first= . > > > > 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. ------ Regards, Alexander Korotkov Supabase