| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Residual tsquery cleanups |
| Date: | 2026-08-17 02:39:31 |
| Message-ID: | 033D6816-517B-47A0-BBEA-0DB37A2B5489@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Aug 17, 2026, at 00:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> The two attached, pretty trivial patches clean up some loose ends
> from the recent tsvector/tsquery security commits. I'm thinking
> of back-patching both, but perhaps there is an argument for not
> back-patching the first one?
>
> regards, tom lane
>
Overall looks good to me. A few small comments:
1 - 0001
```
+ unsigned int dist = pq_getmsgint(buf, sizeof(int16));
+
+ if (dist > MAXENTRYPOS)
+ elog(ERROR, "invalid tsquery: invalid phrase distance %d",
+ dist);
```
Here, “dist” is an unsigned int, so maybe it would be better to use “%u” than “%d” to print it.
2 - 0002
···
+ <para>The length of a <type>tsquery</type>'s data (lexemes only)
+ must be less than 1 megabyte</para>
···
Look like to me this is inaccurate, because in pushValue_internal(), the "if (distance > MAXSTRPOS)” check happens before adding a new element, thus distance may exceed MAXSTRPOS after the element is added.
The doc also says the length of a tsvector must be less than 1 MB, which seems correct, because tsvectorin() checks "if (buflen > MAXSTRPOS)” after the final data length has been calculated.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-08-17 02:42:11 | Re: [BUG] hstore integer overflow when constructing large values |
| Previous Message | wenhui qiu | 2026-08-17 02:19:54 | Re: Prove a NOT IN's left-hand expressions non-nullable from quals |