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
