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 1uP7uL-000tQQ-K5 for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Jun 2025 22:57:29 +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 1uP7uJ-00B8tZ-KN for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Jun 2025 22:57:28 +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 1uP7uJ-00B8tL-Ce for pgsql-bugs@lists.postgresql.org; Tue, 10 Jun 2025 22:57:28 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1uP7uH-001KQ8-1I for pgsql-bugs@lists.postgresql.org; Tue, 10 Jun 2025 22:57:27 +0000 Received: from [192.168.11.2] (p1696134-ipoe.ipoe.ocn.ne.jp [118.0.93.133]) by oss.nttdata.com (Postfix) with ESMTPSA id 58C046093E; Wed, 11 Jun 2025 07:57:20 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com Message-ID: Date: Wed, 11 Jun 2025 07:57:19 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements To: Michael Paquier , Anthonin Bonnefoy Cc: Dilip Kumar , a.kozhemyakin@postgrespro.ru, pgsql-bugs@lists.postgresql.org References: <18947-cdd2668beffe02bf@postgresql.org> <9171ecda-e1f4-4390-ae54-98bc441b98e3@oss.nttdata.com> Content-Language: en-US From: Fujii Masao In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025/06/11 7:39, Michael Paquier wrote: > On Tue, Jun 10, 2025 at 08:14:40PM +0900, Michael Paquier wrote: >> Hmm. I am wondering whether this would be enough; these are not the >> only places where we use select_no_parens and select_with_parens. I'd >> be curious to see what you think a fully-bloomed fix should look like. > > By the way, this report also means that none of the problematic query > patterns are run in the main regression test suite, or we would have > noticed something immediately when running the recovery test > 027_stream_regress.pl that loads PGSS. > > So we have a problem in test coverage with query normalization > patterns. But we also have a second, older, problem in terms of > coverage regarding the parentheses patterns that are assumed as > supported in the parser. Even if we finish by reverting the nested > query tracking support for now (let's settle things before beta2 not > after it), we should definitely improve the main regression test suite > in this area to make sure that reintroducing it safe. Sounds reasonable to me. Also I agree with reverting the commit and revisiting the feature in v19. Regards, -- Fujii Masao NTT DATA Japan Corporation