Re: BUG #15489: Segfault on DELETE

I did do a VACUUM FULL on that one particular table as well, so that may have been the command that fixed it, yes.

I have just upgraded to PG 11.1 and will report if I see this again. Thanks all!

Kanwei

> On Nov 7, 2018, at 8:33 PM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> Thanks Frederico for your reply.
>
> On 2018/11/08 10:10, Frederico Costa Galvão wrote:
>> I stumbled upon this issue yesterday, and trying to reduce and pinpoint
>> it, I managed to get to this:
>>
>> //start
>> CREATE TABLE a (
>> id bigint
>> );
>>
>> INSERT INTO a (id) VALUES (1); -- this id's value doesn't matter
>>
>> ALTER TABLE ONLY a
>> ADD CONSTRAINT a_pkey PRIMARY KEY (id);
>>
>> CREATE TABLE b (
>> a_id bigint
>> );
>>
>> ALTER TABLE ONLY b
>> ADD CONSTRAINT b_a_id_fkey FOREIGN KEY (a_id) REFERENCES a(id);
>>
>> ALTER TABLE a ADD x BOOLEAN NOT NULL DEFAULT FALSE; -- or TRUE, doesn't
>> matter
>
> There it is. These are similar steps as I'd used to track down a bug
> that's now fixed in 11.1.
>
> https://www.postgresql.org/message-id/9cb4aa1c-12ba-59c3-fd75-545fa90fb92f%40lab.ntt.co.jp <https://www.postgresql.org/message-id/9cb4aa1c-12ba-59c3-fd75-545fa90fb92f%40lab.ntt.co.jp>
>
> The bug had to do with foreign key trigger not getting a proper
> representation of the tuple being deleted, considering the newly added column.
>
>> -- VACUUM FULL ANALYZE a; -- uncomment this to fix the bug
>
> Ah, VACUUM FULL will rewrite the tuples such that they're not hit by the
> aforementioned bug.
>
> So, if OP can tell that this is what happened in their case too, then 11.1
> will have fixed the issue.
>
> Thanks,
> Amit