AFAICS, the fast-default patch neglected to consider what happens if a database containing columns with active attmissingval entries is pg_upgraded. I do not see any code in either pg_dump or pg_upgrade that attempts to deal with that situation, which means the effect will be that the "missing" values will silently revert to nulls: they're still null in the table storage, and the restored pg_attribute entries won't have anything saying it should be different.
The pg_upgrade regression test fails to exercise such a case. There is only one table in the ending state of the regression database that has any atthasmissing columns, and it's empty :-(. If I add a table in which there actually are active attmissingval entries, say according to the attached patch, I get a failure in the pg_upgrade test. This is certainly a stop-ship issue, and in fact it's bad enough that I think we may need to pull the feature for v11. Designing binary-upgrade support for this seems like a rather large task to be starting post-beta1. Nor do I think it's okay to wait for v12 to make it work; what if we have to force an initdb later in beta, or recommend use of pg_upgrade for some manual catalog fix after release? regards, tom lane
diff --git a/src/test/regress/expected/fast_default.out b/src/test/regress/expected/fast_default.out index ef8d04f..f3d783c 100644 *** a/src/test/regress/expected/fast_default.out --- b/src/test/regress/expected/fast_default.out *************** DROP TABLE has_volatile; *** 548,550 **** --- 548,561 ---- DROP EVENT TRIGGER has_volatile_rewrite; DROP FUNCTION log_rewrite; DROP SCHEMA fast_default; + -- Leave a table with an active fast default in place, for pg_upgrade testing + set search_path = public; + create table has_fast_default(f1 int); + insert into has_fast_default values(1); + alter table has_fast_default add column f2 int default 42; + table has_fast_default; + f1 | f2 + ----+---- + 1 | 42 + (1 row) + diff --git a/src/test/regress/sql/fast_default.sql b/src/test/regress/sql/fast_default.sql index 0e66033..7b9cc47 100644 *** a/src/test/regress/sql/fast_default.sql --- b/src/test/regress/sql/fast_default.sql *************** DROP TABLE has_volatile; *** 369,371 **** --- 369,378 ---- DROP EVENT TRIGGER has_volatile_rewrite; DROP FUNCTION log_rewrite; DROP SCHEMA fast_default; + + -- Leave a table with an active fast default in place, for pg_upgrade testing + set search_path = public; + create table has_fast_default(f1 int); + insert into has_fast_default values(1); + alter table has_fast_default add column f2 int default 42; + table has_fast_default;