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 1vCfIa-00Gn1S-HV for pgsql-bugs@arkaria.postgresql.org; Sat, 25 Oct 2025 14:31:15 +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 1vCfIX-003GLy-RA for pgsql-bugs@arkaria.postgresql.org; Sat, 25 Oct 2025 14:31:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vCfIX-003GLq-Ic for pgsql-bugs@lists.postgresql.org; Sat, 25 Oct 2025 14:31:12 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vCfIT-003iG3-1C for pgsql-bugs@lists.postgresql.org; Sat, 25 Oct 2025 14:31:11 +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 59PEV5kw1970842; Sat, 25 Oct 2025 10:31:05 -0400 From: Tom Lane To: lori.corbani@jax.org cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19094: select statement on postgres 17 vs postgres 18 is returning different/duplicate results In-reply-to: <19094-6ed410eb5b256abd@postgresql.org> References: <19094-6ed410eb5b256abd@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Fri, 24 Oct 2025 14:23:34 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1970840.1761402665.1@sss.pgh.pa.us> Date: Sat, 25 Oct 2025 10:31:05 -0400 Message-ID: <1970841.1761402665@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > If I remove the "exists" statement, then the counts are fine. > So, it seems that it is the "exists" statement that is causing the issue. > "select s._Strain_key" VS "select distinct s._Strain_key" > from prb_strain s > where s.private = 0 > and s.strain not ilike '%involves%' > and s.strain not ilike '%either%' > and s.strain not ilike '% and %' > and s.strain not ilike '% or %' > and exists (select 1 from voc_annot va, voc_term t > where va._AnnotType_key = 1009 > and va._Term_key = t._Term_key > and t.term != 'Not Applicable' > and t.term != 'Not Specified' > and va._Object_key = s._Strain_key) This report is inadequate to help us identify the issue. You've not provided the relevant table declarations, nor any sample data that would reproduce the problem. Given the squishiness of the described behavior, I realize that building a self-contained reproducer might be hard. In the meantime, could you at least provide EXPLAIN ANALYZE results from correct and incorrect executions? regards, tom lane