Content-Type: multipart/mixed; boundary="------------dVx4irQEQ82jua7UtyHmtugk"
Message-ID: <19d59133-7a9b-4d9f-a439-201d143bdb5f@gmail.com>
Date: Fri, 21 Aug 2026 14:04:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19634: Hash partition with large MODULUS causes "invalid
 memory alloc request size"
To: pgsql-bugs@lists.postgresql.org
References: <19634-c18dfa96a8edc306@postgresql.org>
Content-Language: en-US
Cc: hackerzheng666@gmail.com
From: Pierre Forstmann <pierre.forstmann@gmail.com>
In-Reply-To: <19634-c18dfa96a8edc306@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/19d59133-7a9b-4d9f-a439-201d143bdb5f%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------dVx4irQEQ82jua7UtyHmtugk
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

I propose following patch that adds the check to new_partition_bound 
routine:

postgres=# CREATE TABLE t (id int) PARTITION BY HASH (id);
CREATE TABLE
postgres=# CREATE TABLE t_p0 PARTITION OF t FOR VALUES WITH (MODULUS 
268435457,
REMAINDER 0);
ERROR:  hash partitions bounds are too large
DETAIL:  Creating hash partitions for modulus 268435457 would require 
too much memory.
HINT:  Reduce the number of partitions.
postgres=#


Regards,

Pierre Forstmann

Le 21/08/2026 à 05:44, PG Bug reporting form a écrit :
> 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:
>
> Creating a hash partition with MODULUS >= 268435457 causes an internal error
>    "invalid memory alloc request size" on any subsequent query against the
>    partitioned table. The table becomes permanently unusable — SELECT,
> 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 = greatest_modulus;
>      boundinfo->indexes = palloc_array(int, greatest_modulus);
>
>    When greatest_modulus >= 268435457, this requests 268435457 * 4 =
> 1073741828
>    bytes, exceeding MaxAllocSize (1073741823 = 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
>
>
>
>
--------------dVx4irQEQ82jua7UtyHmtugk
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-v1-0001-Fix-memory-allocation-check.patch"
Content-Disposition: attachment;
 filename="0001-v1-0001-Fix-memory-allocation-check.patch"
Content-Transfer-Encoding: base64

RnJvbSA3Y2E4MGYzM2I4MDZlMmIzMjJlOTYzMWUwMTA0NjE3M2IyNzZlODdlIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQaWVycmUgRm9yc3RtYW5uIDxwaWVycmUuZm9yc3Rt
YW5uQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyMSBBdWcgMjAyNiAxMzo1NjoyOSArMDIwMApT
dWJqZWN0OiBbUEFUQ0hdIHYxLTAwMDEtRml4LW1lbW9yeS1hbGxvY2F0aW9uLWNoZWNrCgot
LS0KIHNyYy9iYWNrZW5kL3BhcnRpdGlvbmluZy9wYXJ0Ym91bmRzLmMgfCAxMCArKysrKysr
KysrCiAxIGZpbGUgY2hhbmdlZCwgMTAgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3Ny
Yy9iYWNrZW5kL3BhcnRpdGlvbmluZy9wYXJ0Ym91bmRzLmMgYi9zcmMvYmFja2VuZC9wYXJ0
aXRpb25pbmcvcGFydGJvdW5kcy5jCmluZGV4IDg2NWE5MmM4NTYxLi4xNWFiMGY3MTVkNCAx
MDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcGFydGl0aW9uaW5nL3BhcnRib3VuZHMuYworKysg
Yi9zcmMvYmFja2VuZC9wYXJ0aXRpb25pbmcvcGFydGJvdW5kcy5jCkBAIC0yOTE4LDYgKzI5
MTgsMTQgQEAgY2hlY2tfbmV3X3BhcnRpdGlvbl9ib3VuZChjaGFyICpyZWxuYW1lLCBSZWxh
dGlvbiBwYXJlbnQsCiAJCQkJQXNzZXJ0KHNwZWMtPnN0cmF0ZWd5ID09IFBBUlRJVElPTl9T
VFJBVEVHWV9IQVNIKTsKIAkJCQlBc3NlcnQoc3BlYy0+cmVtYWluZGVyID49IDAgJiYgc3Bl
Yy0+cmVtYWluZGVyIDwgc3BlYy0+bW9kdWx1cyk7CiAKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLyogQ2hlY2sgbmVlZGVkIG1lbW9yeSB0aGF0IHdpbGwgYmUgYWxsb2Nh
dGVkIGluIGNyZWF0ZV9oYXNoX2JvdW5kcygpICovCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGlmIChzcGVjLT5tb2R1bHVzICogc2l6ZW9mKGludCkgPiBNYXhBbGxvY1Np
emUpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXJlcG9ydChF
UlJPUiwgKGVycmNvZGUoRVJSQ09ERV9QUk9HUkFNX0xJTUlUX0VYQ0VFREVEKSwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJtc2coImhh
c2ggcGFydGl0aW9ucyBib3VuZHMgYXJlIHRvbyBsYXJnZSIpLAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVycmRldGFpbCgiQ3JlYXRpbmcg
aGFzaCBwYXJ0aXRpb25zIGZvciBtb2R1bHVzICVkIHdvdWxkIHJlcXVpcmUgdG9vIG11Y2gg
bWVtb3J5LiIsIHNwZWMtPm1vZHVsdXMpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGVycmhpbnQoIlJlZHVjZSB0aGUgbnVtYmVyIG9mIHBh
cnRpdGlvbnMuIikpKSk7CisKKwogCQkJCWlmIChwYXJ0ZGVzYy0+bnBhcnRzID4gMCkKIAkJ
CQl7CiAJCQkJCWludAkJCWdyZWF0ZXN0X21vZHVsdXM7CkBAIC0zMDMwLDggKzMwMzgsMTAg
QEAgY2hlY2tfbmV3X3BhcnRpdGlvbl9ib3VuZChjaGFyICpyZWxuYW1lLCBSZWxhdGlvbiBw
YXJlbnQsCiAJCQkJCQl9CiAJCQkJCQlyZW1haW5kZXIgKz0gc3BlYy0+bW9kdWx1czsKIAkJ
CQkJfSB3aGlsZSAocmVtYWluZGVyIDwgZ3JlYXRlc3RfbW9kdWx1cyk7CisKIAkJCQl9CiAK
KwogCQkJCWJyZWFrOwogCQkJfQogCi0tIAoyLjQ3LjMKCg==

--------------dVx4irQEQ82jua7UtyHmtugk--