Обсуждение: 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