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

From Andrew Dunstan
Subject Fwd: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default
Date
Msg-id f919005d-c340-0db9-8728-a9602b98ce8f@dunslane.net
Whole thread Raw
List pgsql-hackers
reposting to -hackers to get more eyeballs.


Summary: only RELKIND_RELATION type relations should have attributes
with atthasmissing/attmissingval



-------- Forwarded Message --------
Subject:     Re: BUG #17056: Segmentation fault on altering the type of the
foreign table column with a default
Date:     Sat, 12 Jun 2021 21:59:24 -0400
From:     Andrew Dunstan <andrew@dunslane.net>
To:     Andres Freund <andres@anarazel.de>
CC:     Tom Lane <tgl@sss.pgh.pa.us>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org




On 6/12/21 5:50 PM, Andres Freund wrote:
> 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
>

Yes, you're right. This version should take care of things better.


Thanks for looking.


cheers


andrew


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


Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: a path towards replacing GEQO with something better
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: locking [user] catalog tables vs 2pc vs logical rep