Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u3TUU-00GNVd-5e for pgsql-bugs@arkaria.postgresql.org; Sat, 12 Apr 2025 05:33:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u3TUR-001aGQ-El for pgsql-bugs@arkaria.postgresql.org; Sat, 12 Apr 2025 05:33:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u3TUR-001aGC-5h for pgsql-bugs@lists.postgresql.org; Sat, 12 Apr 2025 05:33:15 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u3TUO-004s1K-2t for pgsql-bugs@lists.postgresql.org; Sat, 12 Apr 2025 05:33:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 53C5X7K31126692; Sat, 12 Apr 2025 01:33:07 -0400 From: Tom Lane To: Vinod Sridharan 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: References: <18831-e845ac44ebc5dd36@postgresql.org> <474911.1741207802@sss.pgh.pa.us> <1026035.1744415680@sss.pgh.pa.us> <1098251.1744426831@sss.pgh.pa.us> Comments: In-reply-to Vinod Sridharan message dated "Fri, 11 Apr 2025 20:30:43 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1126690.1744435987.1@sss.pgh.pa.us> Date: Sat, 12 Apr 2025 01:33:07 -0400 Message-ID: <1126691.1744435987@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Vinod Sridharan writes: > Since this is also called in the regular consistent function, this > would be adding work in the regular consistent path - where the caller > happens to reset the array for every invocation currently. Ah, so you're just worried about the extra work in that path? But MAX_MAYBE_ENTRIES is only 4, so I can't believe it'd amount to much. I am wondering about a test case. I'm not thrilled about building a specialized opclass just to test this. contrib/hstore and contrib/intarray already have opclasses with no triconsistent function, so they should (and do) exercise shimTriConsistentFn already. But their tests failed to expose this bug. I spent a bit of time trying to add an example that would show the bug in one or the other of those, and failed so far. Any ideas? regards, tom lane