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

Поиск
Список
Период
Сортировка
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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17054: Memory corruption in logical replication worker when replicating into partitioned table