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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
Date: 2021-06-11 21:59:07
Message-ID: 43114f0b-69d8-b040-3a46-caedcc77b9fc@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


On 6/10/21 7:11 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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.

The first piece could be fairly simply accomplished by something like this

diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index afa830d924..ac89efefe8 100644
--- a/src/backend/catalog/heap.c
+++ b/src/backend/catalog/heap.c
@@ -2287,7 +2287,8 @@ StoreAttrDefault(Relation rel, AttrNumber attnum,
        valuesAtt[Anum_pg_attribute_atthasdef - 1] = true;
        replacesAtt[Anum_pg_attribute_atthasdef - 1] = true;
 
-       if (add_column_mode && !attgenerated)
+       if (rel->rd_rel->relkind == RELKIND_RELATION  && add_column_mode &&
+           !attgenerated)
        {
            expr2 = expression_planner(expr2);
            estate = CreateExecutorState();

I'm guessing we want to exclude materialized views and partitioned
tables as well as things without local storage.

How to ignore something that's got into the catalog that shouldn't be
there is less clear. At the point where we fetch missing values all we
have access to is a TupleDesc.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Dunstan 2021-06-11 22:03:28 Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
Previous Message Zlatoslav Petukhov 2021-06-11 21:09:45 Re: BUG #17057: Unexpected error: ERROR: unsupported target type: 0

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2021-06-11 22:03:28 Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
Previous Message Peter Geoghegan 2021-06-11 21:46:20 Re: Teaching users how they can get the most out of HOT in Postgres 14