BUG #15247: At 'ALTER TABLE ADD COLUMN fast default' , Set attmissingval to NULL in the pg_attribute, query fail
The following bug has been logged on the website:
Bug reference: 15247
Logged by: guangxian li
Email address: liguangxian1995@gmail.com
PostgreSQL version: 11beta1
Operating system: debian 6.4.0
Description:
Dear developer:
Steps:
(1) create table test(a int);
(2) insert into test values(1),(2),(3);
(3) alter table test add b int not null default 0;
(4) update pg_attribute set attmissingval = NULL where attname = 'b';
(5) select b from test;
Then,query the b field from the test table(select b from test;) , lead to
server closed the connection unexpectedly .
I think this a bug ,or not. Meanwhile,I think we should add an statement
--if(att->atthasmissing && tupleDesc->constr->missing) .Not Assert().
So, Hope to get your reply,Thanks again.
Next is a patch.
--- a/src/backend/access/common/heaptuple.c
+++ b/src/backend/access/common/heaptuple.c
@@ -91,7 +91,7 @@ getmissingattr(TupleDesc tupleDesc,att = TupleDescAttr(tupleDesc, attnum - 1);
- if (att->atthasmissing)
+ if (att->atthasmissing && tupleDesc->constr->missing)
{
AttrMissing *attrmiss;
On Tue, Jun 19, 2018 at 04:19:55AM +0000, PG Bug reporting form wrote:
(1) create table test(a int);
(2) insert into test values(1),(2),(3);
(3) alter table test add b int not null default 0;
(4) update pg_attribute set attmissingval = NULL where attname = 'b';
(5) select b from test;
Then,query the b field from the test table(select b from test;) , lead to
server closed the connection unexpectedly .I think this a bug ,or not. Meanwhile,I think we should add an statement
--if(att->atthasmissing && tupleDesc->constr->missing) .Not Assert().
Well, you are directly manipulating a catalog with a DML query, which is
not a supported operation, so you are shooting yourself in the foot
here. There are many more and various ways to trigger failures.
--
Michael
"PG" == PG Bug reporting form <noreply@postgresql.org> writes:
PG> (4) update pg_attribute set attmissingval = NULL where attname = 'b';
Nobody ever claimed that you could update pg_attribute without crashing
the server; I can think of half a dozen ways to do it.
--
Andrew (irc:RhodiumToad)
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
"PG" == PG Bug reporting form <noreply@postgresql.org> writes:
PG> (4) update pg_attribute set attmissingval = NULL where attname = 'b';
Nobody ever claimed that you could update pg_attribute without crashing
the server; I can think of half a dozen ways to do it.
Specifically, you broke it by not keeping atthasmissing consistent with
attmissingval. Manually corrupting catalogs like that is not a supported
operation.
regards, tom lane