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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Vinod Sridharan <vsridh90(at)gmail(dot)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