Re: Re: BUG #15489: Segfault on DELETE

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

-- VACUUM FULL ANALYZE a; -- uncomment this to fix the bug

DELETE FROM a;
//end

This was the bare minimum I could get to reproduce the segfault on a 
portable way. It's something between foreign keys pointing to tables 
that have gone through the new no-table-rewrite handling of nonnull 
columns with non-volatile default values.

Also, VACUUM ANALYZE itself didn't fix the corrupted data: it needs to 
be FULL.

I'm on <Xubuntu 16.04 x86_64>, with <psql (PostgreSQL) 11.0 (Ubuntu 
11.0-1.pgdg16.04+2)>.
I have some simple custom settings on postgresql.conf that I don't think 
are related to the issue, but I'm willing to provide if needed.

---

Frederico Costa Galvão

On 07/11/2018 05:14, Michael Paquier wrote:
> On Wed, Nov 07, 2018 at 02:34:12PM +0900, Amit Langote wrote:
>> Are there any triggers defined on integration_account?  Also, has there
>> recently been any ALTER TABLE DROP/DROP COLUMN activity on that table?
>>
>> PG 11.1 to be released later this week fixed a bug that would cause
>> segmentation fault when running triggers (including, but not limited to
>> DELETE triggers).
> The point is that without more information about the schema used which
> would allow to build a reproducible test case from the ground, or even
> better a self-contained test case, then there is nothing much we can do
> except assuming about what kind of things have been happening here.
> --
> Michael