| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Residual tsquery cleanups |
| Date: | 2026-08-17 14:46:41 |
| Message-ID: | 753081.1786978001@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> writes:
> 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.
Hmm ... doesn't really matter, since pq_getmsgint's result is
guaranteed to be in 0..65535. But OK.
> 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.
True, it can be up to one lexeme more. But I didn't think it was
worth trying to go into that much detail. As a comparison point,
the corresponding bullet for tsvector doesn't explain how to calculate
the space used for lexeme positions. I think the main takeaway here
is just that there *is* a limit of this type. People who really want
to know the exact details can consult the source code.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-08-17 15:00:00 | Re: Add autovacuum_warning to surface concurrent vacuum collisions |
| Previous Message | Daniel Gustafsson | 2026-08-17 14:38:30 | Re: pg_control_checkpoint(): add "data_checksum_version" (Pg19)? |