Query size limitation missing in documentation
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t77119psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 02:21 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t77119_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t77119_1 && git checkout t77119_1Patchset v1 (message #1) is on t77119_1
Hello,
I was looking at https://www.postgresql.org/docs/current/limits.html
(was brought up by a customer) and found we are missing the limitation
of the string of the SQL to be executed (it's 1GB which is the longest
string postgres can hold)
```
/* It's possible we could use a different value for this in frontend code */
#define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
```
Would there be any objections to adding such limitations in the list
from the link above?
Attached in a proposed patch which adds this to the documentation. I
also added a paragraph mentioning why the field and query length are
limited by 1GB.
--
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see
=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= <martin.marques@gmail.com> writes:
I was looking at https://www.postgresql.org/docs/current/limits.html
(was brought up by a customer) and found we are missing the limitation
of the string of the SQL to be executed (it's 1GB which is the longest
string postgres can hold)
I kind of doubt that this is a useful piece of information, because
there are a bunch of other practical limits you're likely to hit
before that one.
regards, tom lane