Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns.

 -- create textops operator class without triconsistent
 CREATE OPERATOR CLASS mytsvector_ops FOR TYPE tsvector USING gin AS
     OPERATOR 1 @@(tsvector,tsquery),
     OPERATOR 2 @@@(tsvector,tsquery),
     FUNCTION        1       gin_cmp_tslexeme,
     FUNCTION        2       gin_extract_tsvector(tsvector,internal,internal),
     FUNCTION        3
gin_extract_tsquery(tsvector,internal,int2,internal,internal,internal,internal),
     FUNCTION        4
gin_tsquery_consistent(internal,int2,tsvector,int4,internal,internal,internal,internal),
     FUNCTION        5       gin_cmp_prefix,
 STORAGE text;
REATE TABLE mytexttable (value tsvector);

-- insert a single row that has one field in it
INSERT INCREATE OPERATOR CLASS

 -- create a table with a tsvector column
 CREATE TABLE mytexttable (value tsvector);
eate index with the above opclass
CREATE INDEX ON CREATE TABLE

 -- insert a single row that has one field in it
 INSERT INTO mytexttable VALUES ('second'::tsvector);
INSERT 0 1

 -- create index with the opclass above
 CREATE INDEX ON mytexttable USING gin(value mytsvector_ops);
CREATE INDEX

 -- now query (this should return second)
 SELECT * FROM mytexttable WHERE value @@ '(second | third) & !first'::tsquery;
  value
----------
 'second'
(1 row)


 -- this no longer returns the row
set enable_seqscan to off;
SET
 SELECT * FROM mytexttable WHERE value @@ '(second | third) & !first'::tsquery;
 value
-------
(0 rows)

Not sure what the best place would be to add such a test but happy to
add one wherever you recommend.

Thanks,
Vinod

On Fri, 11 Apr 2025 at 16:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Vinod Sridharan <vsridh90@gmail.com> writes:
> > I believe there may be an issue with the above patch - specifically in
> > the case of the triConsistent logic dealing with op-classes that use
> > the consistent function. In the shimTriConsistentFn, the key's
> > entryRes values are directly mutated to set to GIN_FALSE (if there's
> > fewer than MAX_MAYBE_ENTRIES entries). At the end of this method,
> > they're not reset back to GIN_MAYBE. Consequently, the next loop of
> > the ginFillScanEntry now may incorrectly assume that the remaining
> > entries are GIN_FALSE when they started as GIN_MAYBE: previously they
> > were hard reset for every iteration of the ginFillScanEntry loop. The
> > attached patch seems to fix it by resetting any mutated values back
> > before returning. However, this would also reset it during the regular
> > triConsistent check per tuple.
>
> This patch would be more convincing with a test case demonstrating
> that there's a problem.
>
>                         regards, tom lane