Re: Residual tsquery cleanups

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

In response to

Browse pgsql-hackers by date

  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)?