Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns
| От | Peter Eisentraut |
|---|---|
| Тема | Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns |
| Дата | |
| Msg-id | 8e6df41a-d0a3-681f-1ac3-b0e2227103cc@2ndquadrant.com обсуждение исходный текст |
| Ответ на | Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns
Re: BUG #16369: Segmentation Faults and Data Corruption withGenerated Columns |
| Список | 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 по дате отправления: