| From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
|---|---|
| To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Cc: | hackerzheng666(at)gmail(dot)com |
| Subject: | BUG #19634: Hash partition with large MODULUS causes "invalid memory alloc request size" |
| Date: | 2026-08-21 03:44:42 |
| Message-ID: | 19634-c18dfa96a8edc306@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 19634
Logged by: Zheng Hacker
Email address: hackerzheng666(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Rachitskiy | 2026-08-21 05:01:59 | Re: BUG #19633: Unexpected results of IN (subquery) with a non-deterministic collation |
| Previous Message | Tender Wang | 2026-08-21 01:54:23 | Re: BUG #19633: Unexpected results of IN (subquery) with a non-deterministic collation |