Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jPMvh-0007zy-PH for pgsql-bugs@arkaria.postgresql.org; Fri, 17 Apr 2020 09:04:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jPMvg-0002K3-N1 for pgsql-bugs@arkaria.postgresql.org; Fri, 17 Apr 2020 09:04:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jPMvf-0002Jw-IT for pgsql-bugs@lists.postgresql.org; Fri, 17 Apr 2020 09:04:56 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jPMvc-0008CH-4i for pgsql-bugs@lists.postgresql.org; Fri, 17 Apr 2020 09:04:55 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C52B75C0319; Fri, 17 Apr 2020 05:04:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 17 Apr 2020 05:04:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=YAA8z0bw4RlFCZhgrk3HUHO9zlHh0UBGzyr9iPv/A 6c=; b=376uJCWn5bRQxdobXx4zamyVZxL4dCEp1zzdkcPV4CIVz+jcIrqJo2p+2 HzYQ0plrsXeRG1/0dzcdxqDo+ZYctk3Q+EPsfcuEf3E66Y+QM5grQQAKE+quGzMq ZmN2z8rVdYDAEu1jgGVJfO4Sk5m9eOKNFFqj17R3drSDXv90THXLyA0+vtlYVEWg q4FnV75wFvV/0tSrHGHUkdAvlzM9T5fP+55c/gSwHUIKGdVssdOAIPU+R0SL7J/d MYg969l9PqOP9MUHX2uGzecu0FwuV10FVRyF7L8cMUCVmfDv0jeNsFMVawAGuZPW mk4mO1gXjK+Gy5zHL/SMH7jJ9SNGA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeejgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefheenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqh hurggurhgrnhhtrdgtohhmqeenucffohhmrghinhepvdhnughquhgrughrrghnthdrtgho mhenucfkphepleefrddvgedvrddvudefrddvgedunecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhhtsedv nhguqhhurggurhgrnhhtrdgtohhm X-ME-Proxy: Received: from april.pezone.net (p5df2d5f1.dip0.t-ipconnect.de [93.242.213.241]) by mail.messagingengine.com (Postfix) with ESMTPA id DAD4F306005C; Fri, 17 Apr 2020 05:04:47 -0400 (EDT) Subject: Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns To: Michael Paquier , David Rowley References: <16369-5845a6f1bef59884@postgresql.org> <1047.1586994741@sss.pgh.pa.us> <20200416053036.GA81957@paquier.xyz> Cc: Tom Lane , cameron.ezell@clearcapital.com, pgsql-bugs@lists.postgresql.org From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <8e6df41a-d0a3-681f-1ac3-b0e2227103cc@2ndquadrant.com> Date: Fri, 17 Apr 2020 11:04:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200416053036.GA81957@paquier.xyz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-04-16 07:30, Michael Paquier wrote: > On Thu, Apr 16, 2020 at 12:40:24PM +1200, David Rowley wrote: >> On Thu, 16 Apr 2020 at 11:52, Tom Lane wrote: >>> That looks like it'll fail on a null result. >> >> Thanks. I'll have another go then. > > Shouldn't you have more regression test cases here? I guess one for > the non-NULL case, and one for the NULL case? I've tried creating a smaller test case, but it's difficult. I haven't fully understood the reason why it sometimes crashes and sometimes not. The smallest I could come up with so far is something like this: CREATE TABLE crash ( hostname varchar, hostname_short varchar GENERATED ALWAYS AS (hostname) STORED, device text, mount text, used_space_bytes bigint, avail_space_bytes bigint ); INSERT INTO crash (hostname, device, mount, used_space_bytes, avail_space_bytes) VALUES (repeat('1234567890', 100), 'devtmpfs', '/dev', 0, 6047076131313); Would this be easier to reproduce with one of the memory-cleaning #defines enabled? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services