Handle MAXSTRLEN consistently
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.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
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:t253393psql -h localhost -U postgresBuilt from patchset v2 (message #2), August 12, 2026 at 07:18 PM.
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 t253393_2 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 t253393_2 && git checkout t253393_2Patchset v2 (message #2) is on t253393_2
Hello!
Commit 23d9ad77181 added additional length checks for tsvector, but it
is inconsistent at one place: most checks use toklen > MAXSTRLEN as
the error condition, but array_to_tsvector uses >=. This causes a
strange corner-case issue: we can convert a 2047 length lexeme to an
array, as tsvector_to_array allows it, but we can't convert it back
with array_to_tsvector as it errors out.
0001 is a fix for this specific case.
After looking into this further, I realized that the length handling
is also inconsistent at other places, even before the mentioned
commit.
0002 addresses the other preexisting places that used >= for errors instead of >
Attachments:
t253393_10001-Allow-maximum-length-lexemes-in-array_to_tsvector-ag.patchapplication/octet-stream; name=0001-Allow-maximum-length-lexemes-in-array_to_tsvector-ag.patchDownload+14-3
0002-Accept-maximum-length-lexemes-in-all-text-search-inp.patchapplication/octet-stream; name=0002-Accept-maximum-length-lexemes-in-all-text-search-inp.patchDownload+60-7
Zsolt Parragi <zsolt.parragi@percona.com> writes:
Commit 23d9ad77181 added additional length checks for tsvector, but it
is inconsistent at one place: most checks use toklen > MAXSTRLEN as
the error condition, but array_to_tsvector uses >=. This causes a
strange corner-case issue: we can convert a 2047 length lexeme to an
array, as tsvector_to_array allows it, but we can't convert it back
with array_to_tsvector as it errors out.
0001 is a fix for this specific case.
After looking into this further, I realized that the length handling
is also inconsistent at other places, even before the mentioned
commit.
Yeah. I noticed this inconsistency while preparing 23d9ad771,
but felt that fixing it was out of scope for a security patch.
There's a similar problem with inconsistent enforcement of
MAXSTRPOS. Attached is what I had staged to propose post-release.
regards, tom lane
On Wed, 12 Aug 2026, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yeah. I noticed this inconsistency while preparing 23d9ad771,
but felt that fixing it was out of scope for a security patch.
There's a similar problem with inconsistent enforcement of
MAXSTRPOS. Attached is what I had staged to propose post-release.
Yeah, I missed that MAXSTRPOS case but it is also valid, otherwise the changes look identical.
Zsolt Parragi <zsolt.parragi@percona.com> writes:
On Wed, 12 Aug 2026, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yeah. I noticed this inconsistency while preparing 23d9ad771,
but felt that fixing it was out of scope for a security patch.
There's a similar problem with inconsistent enforcement of
MAXSTRPOS. Attached is what I had staged to propose post-release.
Yeah, I missed that MAXSTRPOS case but it is also valid, otherwise the
changes look identical.
Pushed, thanks for the cross-check.
regards, tom lane