Re: BUG #15489: Segfault on DELETE - Mailing list pgsql-bugs

From Kanwei Li
Subject Re: BUG #15489: Segfault on DELETE
Date
Msg-id 36AB7969-AD14-4793-8C6E-21EDC293DE93@gmail.com
Whole thread Raw
In response to Re: BUG #15489: Segfault on DELETE  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-bugs
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@lab.ntt.co.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

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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15493: Wrong name of fields/missing fields for the internal statistic
Next
From: Tom Lane
Date:
Subject: Re: BUG #15479: Documentation claims that client_min_messages is related to logging