From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
Date: Thu, 10 Jun 2021 19:11:03 -0400
Message-ID: <1816295.1623366663@sss.pgh.pa.us> (raw)
In-Reply-To: <4726f847-68fb-a7fc-c5e9-7b9536046fc4@dunslane.net>
References: <17056-4f6f7243d322be6b@postgresql.org>
<1806408.1623363029@sss.pgh.pa.us>
<4726f847-68fb-a7fc-c5e9-7b9536046fc4@dunslane.net>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@dunslane.net, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
In-Reply-To: <1816295.1623366663@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox