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 1taomR-005Qn2-Gd for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Jan 2025 04:25:23 +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 1taomQ-009lNw-Hg for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Jan 2025 04:25:22 +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 1taomQ-009lNo-8X for pgsql-hackers@lists.postgresql.org; Thu, 23 Jan 2025 04:25:22 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1taomN-0011ru-0v for pgsql-hackers@postgresql.org; Thu, 23 Jan 2025 04:25:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=+PeHXcJEL8PUo+pBqfKtF43cLPMgkzmCzdBasZh4Pbc=; b=EuGQiJpQW8kZdze/CmPId6Asoa J81p4vnjw/xUKWzLBo3OUSzV9MOqcBvOqQgxLqOT/rLu7ArB1AG8bAReeR4B9AzqA6vn0hzfHPuET U4BrwgD6b3zhy/Z1gKB8aIdh7aMEpR1syZLJ+wJtSoJrw9s13OSmPl5LRmsqvneGF/7gfPqkYdTNP 5dOtjN2aPy6qtmpL7jgZKCKW+O2HYufI05RMv+qZBOe475rSejvGQqs/vQ0AX1cEDOiy0gyKAZLao sECQ7bMpAt/RPb/lm3xHab6El6Ur775wFJN1nykcgDf17Z9RRcD3M7mIfr6riyl40noZDXxngqb/T 48QNomRA==; Received: from [2409:11:4120:300:949d:ead4:19d6:78fe] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from ) id 1taomI-00BXKB-Jy; Thu, 23 Jan 2025 04:25:17 +0000 Date: Thu, 23 Jan 2025 13:25:02 +0900 (JST) Message-Id: <20250123.132502.1946260197628893279.ishii@postgresql.org> To: krasiyan@gmail.com Cc: ojford@gmail.com, tgl@sss.pgh.pa.us, vik@postgresfriends.org, pgsql-hackers@postgresql.org, andrew@tao11.riddles.org.uk, david@fetter.org Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options From: Tatsuo Ishii In-Reply-To: References: <20250122.205818.930169577391749915.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:949d:ead4:19d6:78fe (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Hello, > I also played with the v4 patch and it produces correct result: > test=# SELECT x,y,lead(y) IGNORE NULLS OVER (ORDER BY x) FROM > (VALUES(1,NULL),(2,2),(3,NULL)) AS v(x,y); > x | y | lead > ---+---+------ > 1 | | 2 > 2 | 2 | > 3 | | > (3 rows) > > test=# > It is from today's git, clean compile and install with only v4 patch > applied, make check also passes without errors. I guess you are just lucky. In my case I enabled --enable-cassert to build PostgreSQL and it automatically turn on CLOBBER_FREED_MEMORY and freed memory area is scrambled. If I look the patch closer, I found a problem: +void +WinCheckAndInitializeNullTreatment(WindowObject winobj, : : + winobj->win_nonnulls = palloc_array(int64, 16); WinCheckAndInitializeNullTreatment is called in each built-in window function. Window functions are called in the per tuple memory context, which means win_nonnulls disappears when next tuple is supplied to the window function. If my understanding is correct, winobj->win_nonnulls needs to survive across processing tuples. Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp