cockroachdb / cockroachdb/cockroach
to_tsvector max size of 1048575 bytes not being honoured.
- Dominant language
- Go
- Stars
- 32.5k
- Forks
- 4.1k
- PR merge metrics
- PR metrics pending
Description
Postgres limits the max size of tsvector at 1 MiB and 16383 position cap.
When tested on cockroachDB the 1 MiB is not honoured and completes without error but the position cap seems to be honoured.
Postgres
#######
demo_database=> SELECT to_tsvector('english',
string_agg('word' || g, ' ')
)
FROM generate_series(1, 1200000) AS g;
ERROR: string is too long for tsvector (17179806 bytes, max 1048575 bytes)
demo_database=>
CRDB
#####
word999989':16383 'word99999':16383 'word999990':16383 'word999991':16383 'word999992':16383 'word999993':16383 'word999994':16383 'word999995':16383 'word999996':16383 'word999997':16383 'word999998':16383 'word999999':16383
(1 row)
Time: 1.463s total (execution 0.818s / network 0.645s)
Note: an additional delay of 1.264650167s was spent formatting the results.
You can use \set display_format to change the formatting.
root@:26257/defaultdb>
The expectation was that CRDB would have the same size limit as Postgres.
Environment:**
- CockroachDB : version 26.2
- Server OS : MacOS
- Client app : cockroach sql
Jira issue: CRDB-65832
Contributor guide
Research direction
Start by reproducing the to_tsvector queries from the issue in CockroachDB 26.2 and compare the result with PostgreSQL's 1 MiB error. Trace the to_tsvector entry point and its size handling, then verify that oversized vectors fail at the expected limit while the 16383 position cap remains honored.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- postgres, sql
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 62/100