Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns - Mailing list pgsql-bugs

From Peter Eisentraut
Subject Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns
Date
Msg-id 8e6df41a-d0a3-681f-1ac3-b0e2227103cc@2ndquadrant.com
Whole thread Raw
In response to Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns
Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns
List pgsql-bugs
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 <tgl@sss.pgh.pa.us> 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



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #16373: Behavior of Temporary table creation
Next
From: David Rowley
Date:
Subject: Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns