Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default

Hi,

On 2021-06-12 17:40:38 -0400, Andrew Dunstan wrote:
> Ok, I think the attached is the least we need to do. Given this I
> haven't been able to induce a crash even when the catalog is hacked with
> bogus missing values on a foreign table. But I'm not 100% convinced I
> have fixed all the places that need to be fixed.

Hm. There's a few places that look at atthasmissing and just assume that
there's corresponding information about the missing field. And as far as
I can see the proposed changes in RelationBuildTupleDesc() don't unset
atthasmissing, they just prevent the constraint part of the tuple desc
from being filled. Wouldn't this cause problems if we reach code like

Datum
getmissingattr(TupleDesc tupleDesc,
int attnum, bool *isnull)
{
Form_pg_attribute att;

Assert(attnum <= tupleDesc->natts);
Assert(attnum > 0);

att = TupleDescAttr(tupleDesc, attnum - 1);

if (att->atthasmissing)
{
AttrMissing *attrmiss;

Assert(tupleDesc->constr);
Assert(tupleDesc->constr->missing);

attrmiss = tupleDesc->constr->missing + (attnum - 1);

if (attrmiss->am_present)

Greetings,

Andres Freund