Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
Date
Msg-id 1816295.1623366663@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default  (Andrew Dunstan <andrew@dunslane.net>)
Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-bugs
Andrew Dunstan <andrew@dunslane.net> writes:
> On 6/10/21 6:10 PM, Tom Lane wrote:
>> Hmm.  The equivalent DDL on a plain table works fine, but this is
>> crashing in the code that manipulates attmissingval.  I suspect some
>> confusion about whether a foreign table column should even *have*
>> attmissingval.  Andrew, any thoughts?

> My initial thought would be that it should not. If the foreign table has
> rows with missing columns then it should be up to the foreign server to
> supply them transparently. We have no notion what the foreign semantics
> of missing columns are.

Yeah, that was kind of what I thought.  Probably only RELKIND_RELATION
rels should ever have attmissingval; but certainly, anything without
local storage should not.

> I can take a look at a fix tomorrow. My inclination would be simply to
> skip setting attmissingval for foreign tables.

Seems like in addition to that, we'll need a defense in this specific
code to cope with the case where the foreign column already has an
attmissingval.  Or maybe, the logic to not store a new one will be enough
to keep us from reaching this crash; but we need to be sure it is enough.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
Next
From: Tom Lane
Date:
Subject: Re: BUG #17054: Memory corruption in logical replication worker when replicating into partitioned table