From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vinod Sridharan <vsridh90@gmail.com>
cc: niek.brasa@hitachienergy.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18831: Particular queries using gin-indexes are not
 interruptible, resulting is resource usage concerns.
In-reply-to: 
 <CAFMdLD7XzsXfi1+DpTqTgrD8XU0i2C99KuF=5VHLWjx4C1pkcg@mail.gmail.com>
References: <18831-e845ac44ebc5dd36@postgresql.org>
 <474911.1741207802@sss.pgh.pa.us>
 <CAFMdLD7XzsXfi1+DpTqTgrD8XU0i2C99KuF=5VHLWjx4C1pkcg@mail.gmail.com>
Comments: In-reply-to Vinod Sridharan <vsridh90@gmail.com>
	message dated "Fri, 11 Apr 2025 16:38:29 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1026034.1744415680.1@sss.pgh.pa.us>
Date: Fri, 11 Apr 2025 19:54:40 -0400
Message-ID: <1026035.1744415680@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1026035.1744415680%40sss.pgh.pa.us>
Precedence: bulk

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