pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #16369: Segmentation Faults and Data Corruption with Generated Columns
10+ messages / 6 participants
[nested] [flat]
Commits from this thread:
2020-04-18 3cb02e307e a375f11c44 Fix possible crash with GENERATED ALWAYS columns
* BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
@ 2020-04-15 20:20 PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: PG Bug reporting form @ 2020-04-15 20:20 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: cameron.ezell@clearcapital.com
The following bug has been logged on the website:
Bug reference: 16369
Logged by: Cameron Ezell
Email address: cameron.ezell@clearcapital.com
PostgreSQL version: 12.2
Operating system: CentOS 8, Red Hat 8, Mac OS X 10.14.6
Description:
It seems that there are a few bugs that are throwing segmentation faults and
causing data corruption. These issues keep appearing for our team when using
tables that contain generated columns introduced in PostgreSQL 12. This has
been tested on 12.2 & 12.1 on CentOS 8 as well as 12.1 on MacOS 10.14.6:
select version();
-- PostgreSQL 12.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.3
20140911 (Red Hat 4.8.3-9), 64-bit
CREATE SCHEMA if not exists test;commit;
CREATE TABLE if not exists test.bug_report
(
id bigint generated by default as identity,
hostname varchar,
hostname_short varchar GENERATED ALWAYS AS (split_part(hostname, '.',
1)) STORED,
device text,
mount text,
used_space_bytes bigint,
used_space_gb numeric GENERATED ALWAYS AS (ROUND(used_space_bytes /
1073741824.0,2)) STORED,
avail_space_bytes bigint,
avail_space_gb numeric GENERATED ALWAYS AS (ROUND(avail_space_bytes /
1073741824.0,2)) STORED,
inserted_dts timestamp with time zone NOT NULL DEFAULT
clock_timestamp(),
inserted_by text NOT NULL DEFAULT session_user
);commit;
-- No problems on the following insert
INSERT INTO test.bug_report(hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('123456789', 'devtmpfs', '/dev', 0,
6047076131313);
select * from test.bug_report;commit;
-- On CentOS 8, this bug is triggered with a hostname with 10+ characters.
On MacOS 10.14.6, 19+ characters.
INSERT INTO test.bug_report(hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('12345678901234567890', 'devtmpfs', '/dev', 0,
6047076131313);commit;
-- This should immediately crash the postgres service
-- Inserting some strings below that character threshold will insert just
fine, but a select statement on the table will now throw an error
INSERT INTO test.bug_report(hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('abc', 'devtmpfs', '/dev', 0,
6047076131313);commit;
select * from test.bug_report;commit;
--ERROR: XX000: invalid memory alloc request size 18446744073709551613
--LOCATION: palloc, mcxt.c:934
-- Once the "hostname_short" column no longer references any other column, I
am unable to reproduce this error
CREATE TABLE if not exists test.bug_report2
(
id bigint generated by default as identity,
hostname varchar,
hostname_short varchar GENERATED ALWAYS AS ('static_string') STORED,
device text,
mount text,
used_space_bytes bigint,
used_space_gb numeric GENERATED ALWAYS AS (ROUND(used_space_bytes /
1073741824.0,2)) STORED,
avail_space_bytes bigint,
avail_space_gb numeric GENERATED ALWAYS AS (ROUND(avail_space_bytes /
1073741824.0,2)) STORED,
inserted_dts timestamp with time zone NOT NULL DEFAULT
clock_timestamp(),
inserted_by text NOT NULL DEFAULT session_user
);commit;
INSERT INTO test.bug_report2(hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('12345678901234567890', 'devtmpfs', '/dev', 0,
6047076131313);commit;
select * from test.bug_report2;commit;
INSERT INTO test.bug_report2(hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('abc', 'devtmpfs', '/dev', 0,
6047076131313);commit;
select * from test.bug_report2;commit;
-- simply referencing another column in the generated column will cause a
crash
CREATE TABLE if not exists test.bug_report3
(
id bigint generated by default as identity,
hostname varchar,
hostname_short varchar GENERATED ALWAYS AS (hostname) STORED,
device text,
mount text,
used_space_bytes bigint,
used_space_gb numeric GENERATED ALWAYS AS (ROUND(used_space_bytes /
1073741824.0,2)) STORED,
avail_space_bytes bigint,
avail_space_gb numeric GENERATED ALWAYS AS (ROUND(avail_space_bytes /
1073741824.0,2)) STORED,
inserted_dts timestamp with time zone NOT NULL DEFAULT
clock_timestamp(),
inserted_by text NOT NULL DEFAULT session_user
);commit;
-- immediate crash
INSERT INTO test.bug_report3(hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('12345678901234567890', 'devtmpfs', '/dev', 0,
6047076131313);commit;
-- no crash on insert
INSERT INTO test.bug_report3(hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('abc', 'devtmpfs', '/dev', 0,
6047076131313);commit;
-- error thrown on select
select * from test.bug_report3;commit;
--ERROR: XX000: invalid memory alloc request size 18446744073709551613
--LOCATION: palloc, mcxt.c:934
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
@ 2020-04-15 23:35 ` David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: David Rowley @ 2020-04-15 23:35 UTC (permalink / raw)
To: cameron.ezell@clearcapital.com; pgsql-bugs@lists.postgresql.org; peter.eisentraut@2ndquadrant.com
On Thu, 16 Apr 2020 at 08:53, PG Bug reporting form
<noreply@postgresql.org> wrote:
> -- On CentOS 8, this bug is triggered with a hostname with 10+ characters.
> On MacOS 10.14.6, 19+ characters.
> INSERT INTO test.bug_report(hostname, device, mount, used_space_bytes,
> avail_space_bytes) VALUES ('12345678901234567890', 'devtmpfs', '/dev', 0,
> 6047076131313);commit;
> -- This should immediately crash the postgres service
--LOCATION: palloc, mcxt.c:934
Thanks for the report. This is certainly a bug.
I slightly simplified the test case to become:
drop table if exists crash;
CREATE TABLE crash (
id bigint generated by default as identity,
hostname varchar,
hostname_short varchar GENERATED ALWAYS AS (hostname) STORED,
device text,
mount text,
used_space_bytes bigint,
used_space_gb bigint GENERATED ALWAYS AS (used_space_bytes) STORED,
avail_space_bytes bigint,
avail_space_gb bigint GENERATED ALWAYS AS (avail_space_bytes) STORED,
inserted_dts timestamp with time zone NOT NULL DEFAULT clock_timestamp(),
inserted_by text NOT NULL DEFAULT session_user
);
INSERT INTO crash (hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('12345678901234567', 'devtmpfs', '/dev', 0,
6047076131313); -- no crash
INSERT INTO crash (hostname, device, mount, used_space_bytes,
avail_space_bytes) VALUES ('123456789012345678', 'devtmpfs', '/dev',
0, 6047076131313); -- crash
The crash occurs during ExecComputeStoredGenerated() when calculating
the hostname_short column. When we call ExecEvalExpr() for that
column, the eval function just returns the value of the Datum in the
"hostname" column, which is stored in "slot". This happens to be a
pointer into the tuple. This results in a crash because, later in that
function, we do ExecClearTuple(slot), which frees the memory for that
tuple.
I suppose it normally works because generally the calculation will be
using some SQL function which will return some calculated value which
is allocated, but in this case, we just return the pointer to the
memory in the tuple slot.
I'd say the fix should be to just datumCopy() the result of the
calculation. i.e the attached.
David
Attachments:
fix_generated_column_crash.patch (application/octet-stream, 661B) download
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index d71c0a4322..9ff6bdd439 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -334,7 +334,8 @@ ExecComputeStoredGenerated(EState *estate, TupleTableSlot *slot, CmdType cmdtype
econtext = GetPerTupleExprContext(estate);
econtext->ecxt_scantuple = slot;
- val = ExecEvalExpr(resultRelInfo->ri_GeneratedExprs[i], econtext, &isnull);
+ val = datumCopy(ExecEvalExpr(resultRelInfo->ri_GeneratedExprs[i], econtext, &isnull),
+ attr->attbyval, attr->attlen);
values[i] = val;
nulls[i] = isnull;
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
@ 2020-04-15 23:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-04-16 00:40 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2020-04-15 23:52 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: cameron.ezell@clearcapital.com; pgsql-bugs@lists.postgresql.org; peter.eisentraut@2ndquadrant.com
David Rowley <dgrowleyml@gmail.com> writes:
> I'd say the fix should be to just datumCopy() the result of the
> calculation. i.e the attached.
That looks like it'll fail on a null result.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-04-16 00:40 ` David Rowley <dgrowleyml@gmail.com>
2020-04-16 05:30 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 10+ messages in thread
From: David Rowley @ 2020-04-16 00:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: cameron.ezell@clearcapital.com; pgsql-bugs@lists.postgresql.org; peter.eisentraut@2ndquadrant.com
On Thu, 16 Apr 2020 at 11:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > I'd say the fix should be to just datumCopy() the result of the
> > calculation. i.e the attached.
>
> That looks like it'll fail on a null result.
Thanks. I'll have another go then.
Attachments:
fix_generated_column_crash2.patch (application/octet-stream, 666B) download
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index d71c0a4322..270d34684e 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -336,6 +336,13 @@ ExecComputeStoredGenerated(EState *estate, TupleTableSlot *slot, CmdType cmdtype
val = ExecEvalExpr(resultRelInfo->ri_GeneratedExprs[i], econtext, &isnull);
+ /*
+ * We must make a copy of val as we have no guarantees about where
+ * memory for pass-by-ref Dataums is located.
+ */
+ if (!isnull)
+ val = datumCopy(val, attr->attbyval, attr->attlen);
+
values[i] = val;
nulls[i] = isnull;
}
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Tom Lane <tgl@sss.pgh.pa.us>
2020-04-16 00:40 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
@ 2020-04-16 05:30 ` Michael Paquier <michael@paquier.xyz>
2020-04-17 09:04 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-04-18 02:13 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
0 siblings, 2 replies; 10+ messages in thread
From: Michael Paquier @ 2020-04-16 05:30 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; cameron.ezell@clearcapital.com; pgsql-bugs@lists.postgresql.org; peter.eisentraut@2ndquadrant.com
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?
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Tom Lane <tgl@sss.pgh.pa.us>
2020-04-16 00:40 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-16 05:30 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Michael Paquier <michael@paquier.xyz>
@ 2020-04-17 09:04 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-04-17 10:01 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-17 17:06 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Terry Schmitt <tschmitt@schmittworks.com>
1 sibling, 2 replies; 10+ messages in thread
From: Peter Eisentraut @ 2020-04-17 09:04 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; David Rowley <dgrowleyml@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; cameron.ezell@clearcapital.com; pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Tom Lane <tgl@sss.pgh.pa.us>
2020-04-16 00:40 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-16 05:30 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Michael Paquier <michael@paquier.xyz>
2020-04-17 09:04 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
@ 2020-04-17 10:01 ` David Rowley <dgrowleyml@gmail.com>
1 sibling, 0 replies; 10+ messages in thread
From: David Rowley @ 2020-04-17 10:01 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Tom Lane <tgl@sss.pgh.pa.us>; cameron.ezell@clearcapital.com; pgsql-bugs@lists.postgresql.org
On Fri, 17 Apr 2020 at 21:04, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> 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?
I've done a bit more work on this and have something close. The case I
came up with for it was:
+CREATE TABLE gtest_varlena (a varchar, b varchar GENERATED ALWAYS AS
(a) STORED);
+INSERT INTO gtest_varlena (a) VALUES('01234567890123456789');
+INSERT INTO gtest_varlena (a) VALUES(NULL);
+SELECT * FROM gtest_varlena ORDER BY a;
+ a | b
+----------------------+----------------------
+ 01234567890123456789 | 01234567890123456789
+ |
+(2 rows)
+
+DROP TABLE gtest_varlena;
With that, on an unpatched server, there's no crash, but there's
clearly junk in the b column.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Tom Lane <tgl@sss.pgh.pa.us>
2020-04-16 00:40 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-16 05:30 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Michael Paquier <michael@paquier.xyz>
2020-04-17 09:04 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
@ 2020-04-17 17:06 ` Terry Schmitt <tschmitt@schmittworks.com>
1 sibling, 0 replies; 10+ messages in thread
From: Terry Schmitt @ 2020-04-17 17:06 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Michael Paquier <michael@paquier.xyz>; David Rowley <dgrowleyml@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; cameron.ezell@clearcapital.com; pgsql-bugs@lists.postgresql.org
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:
>
>
For context, I work with Cameron, who submitted this bug.
I totally agree with Peter on this. We tried to simplify the test case on
our end, but the symptoms would change in odd ways. Changing the column
order would change the symptoms slightly and at times the columns with
DEFAULT values would be corrupt. It also seemed like string text based
columns would behave differently than integers.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Tom Lane <tgl@sss.pgh.pa.us>
2020-04-16 00:40 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-16 05:30 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Michael Paquier <michael@paquier.xyz>
@ 2020-04-18 02:13 ` David Rowley <dgrowleyml@gmail.com>
2020-04-18 09:28 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 10+ messages in thread
From: David Rowley @ 2020-04-18 02:13 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; cameron.ezell@clearcapital.com, pgsql-bugs@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
On Thu, 16 Apr 2020 at 17:30, Michael Paquier <michael@paquier.xyz> wrote:
> Shouldn't you have more regression test cases here? I guess one for
> the non-NULL case, and one for the NULL case?
Yeah. I've just pushed a fix that included a fairly simple regression test.
David
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Tom Lane <tgl@sss.pgh.pa.us>
2020-04-16 00:40 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
2020-04-16 05:30 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns Michael Paquier <michael@paquier.xyz>
2020-04-18 02:13 ` Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns David Rowley <dgrowleyml@gmail.com>
@ 2020-04-18 09:28 ` Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 10+ messages in thread
From: Michael Paquier @ 2020-04-18 09:28 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; cameron.ezell@clearcapital.com, pgsql-bugs@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
On Sat, Apr 18, 2020 at 02:13:17PM +1200, David Rowley wrote:
> On Thu, 16 Apr 2020 at 17:30, Michael Paquier <michael@paquier.xyz> wrote:
> > Shouldn't you have more regression test cases here? I guess one for
> > the non-NULL case, and one for the NULL case?
>
> Yeah. I've just pushed a fix that included a fairly simple regression test.
Thanks for the commit, David! I was wondering if it would have been
better to add a "\pset null", but that's a nit and the result looks
fine anyway.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2020-04-18 09:28 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-04-15 20:20 BUG #16369: Segmentation Faults and Data Corruption with Generated Columns PG Bug reporting form <noreply@postgresql.org>
2020-04-15 23:35 ` David Rowley <dgrowleyml@gmail.com>
2020-04-15 23:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-04-16 00:40 ` David Rowley <dgrowleyml@gmail.com>
2020-04-16 05:30 ` Michael Paquier <michael@paquier.xyz>
2020-04-17 09:04 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-04-17 10:01 ` David Rowley <dgrowleyml@gmail.com>
2020-04-17 17:06 ` Terry Schmitt <tschmitt@schmittworks.com>
2020-04-18 02:13 ` David Rowley <dgrowleyml@gmail.com>
2020-04-18 09:28 ` Michael Paquier <michael@paquier.xyz>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox