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 1wxHvE-002a6W-1x for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Aug 2026 05:36:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wxHvC-00Bi3i-1W for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Aug 2026 05:36:06 +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 1wxGBn-00BMBn-2b for pgsql-bugs@lists.postgresql.org; Fri, 21 Aug 2026 03:45:07 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wxGBm-00000001gKk-1Ezn for pgsql-bugs@lists.postgresql.org; Fri, 21 Aug 2026 03:45:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=ToVQhMKTQ7NHJRbdcHqZpsX5NUZ87YCQHnckBnEBAos=; b=D4Dzz2kMU3/ImeA+K94EvqzVMR ZSTWxmCvJmVIdZuOUIwfEtMATtE14Nj2na3ld919oEiT2OSzqmIEPJdhWr3L+n7h9663zeaMUu5Vd iEW40xfNtRN/GX5Ql/mnlCpAnTXSlZOWJRrX1UcDoW4fk6Tp8fQx08whz4zQvqVa8FLvPhpAvPJOE sCgwSc0OhfRt7AMHDbyy/j3Lp1LlFPLTMGoKbr2t7n0unq9/WisEhQX4mOibyQ1d+MzOagxxm4FbO SOKZqM394UkSkm0LaiVcxnJanpAeXKa/GtbQku7tmCTMig+HjgNAwDrR0EJsswYYmnzj0PuE0n7r4 FtaZEnJA==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wxGBl-0052eB-35 for pgsql-bugs@lists.postgresql.org; Fri, 21 Aug 2026 03:45:06 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1wxGBk-0000000DNXK-2sB0 for pgsql-bugs@lists.postgresql.org; Fri, 21 Aug 2026 03:45:04 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19634: Hash partition with large MODULUS causes "invalid memory alloc request size" To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: hackerzheng666@gmail.com Reply-To: hackerzheng666@gmail.com, pgsql-bugs@lists.postgresql.org Date: Fri, 21 Aug 2026 03:44:42 +0000 Message-ID: <19634-c18dfa96a8edc306@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19634 Logged by: Zheng Hacker Email address: hackerzheng666@gmail.com PostgreSQL version: 19beta3 Operating system: Linux x86_64 Description: =20 Creating a hash partition with MODULUS >=3D 268435457 causes an internal er= ror "invalid memory alloc request size" on any subsequent query against the partitioned table. The table becomes permanently unusable =E2=80=94 SELEC= T, INSERT, and all other operations fail with the same error. Only DROP TABLE works. Minimal reproducer (tested on PG 20devel commit 609f969, 2026-08-21): CREATE TABLE t (id int) PARTITION BY HASH (id); CREATE TABLE t_p0 PARTITION OF t FOR VALUES WITH (MODULUS 268435457, REMAINDER 0); SELECT * FROM t; -- ERROR: invalid memory alloc request size 1073741828 Root cause: In src/backend/partitioning/partbounds.c, create_hash_bounds() (line 390) allocates an array indexed by greatest_modulus: boundinfo->nindexes =3D greatest_modulus; boundinfo->indexes =3D palloc_array(int, greatest_modulus); When greatest_modulus >=3D 268435457, this requests 268435457 * 4 =3D 1073741828 bytes, exceeding MaxAllocSize (1073741823 =3D 1GB - 1). No bounds check exists on the modulus value before this allocation. The validation in check_new_partition_bound() (line ~2927) runs AFTER create_hash_bounds() is called during partition descriptor loading, so it never gets a chance to reject the invalid modulus. Impact: - Affects all versions since hash partitioning was introduced (PG 11+) - The partition is created successfully (CREATE TABLE succeeds) - But any access to the parent table fails permanently - Only DROP TABLE recovers the table - Any unprivileged user with CREATE TABLE permission can trigger this Suggested fix: Add a bounds check in create_hash_bounds() before the allocation, or validate modulus against MaxAllocSize in check_new_partition_bound() before partition descriptor loading. PostgreSQL version: 20devel (commit 609f969) OS: Ubuntu 22.04 x86_64