On Mon, 9 Nov 2026 at 18:27, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19856
> Logged by: Atish Prakash
> Email address: 125atishprak(at)gmail(dot)com
> PostgreSQL version: 18.6
> Operating system: Linux x86_64
> Description:
>
> A GiST index on a tsquery column can miss rows holding an empty tsquery for
> "column <@ query". No error is raised, apart from the usual NOTICE about a
> query with
> no lexemes.
>
> CREATE TABLE q(c tsquery);
> INSERT INTO q SELECT (ARRAY['', 'a', 'a & b', 'a | b', '!a',
> 'b:*']::tsquery[])[1 + i % 6]
> FROM generate_series(1, 600) i;
>
> SELECT count(*) FROM q WHERE c <@ 'zz'; -- 100
> SELECT count(*) FROM q WHERE c <@ ''; -- 100
>
> CREATE INDEX ON q USING gist (c);
> SET enable_seqscan = off;
>
> SELECT count(*) FROM q WHERE c <@ 'zz'; -- 0, expected 100
> SELECT count(*) FROM q WHERE c <@ ''; -- 0, expected 100
>
> Cause: an empty tsquery has an all-zero signature. For
> RTContainedByStrategyNumber on
> an internal page, gtsquery_consistent() descends only if (key & sq) != 0. A
> subtree can
> hold empty entries, which are contained by anything, even when its union
> key
> does not
> overlap the query, so that subtree is skipped.
>
> This looks like the same mistake as the intarray report "intarray GiST
> index
> gets wrong
> answers for '{}' <@ anything":
> https://www.postgresql.org/message-id/458.1565114141@sss.pgh.pa.us
>
> A possible patch is attached (0001-fix-tsquery-gist-contained-by.patch). It
> always
> descends for this strategy on internal pages, as the signature cannot rule
> out empty
> entries. That makes <@ scans visit the whole index, a cost a maintainer may
> want to
> weigh. With it, the queries above return 100, and all 239 core regression
> tests pass on
> master. It adds no new test.
>
> Empty tsquery values are probably rare in practice, so this is low
> severity.
>
> Found by comparing index and sequential scans across the operator classes
> listed in
> the catalog. I reproduced and checked the result myself.
>
>
>