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 pinpointit, I managed to get to this://startCREATE TABLE a ( id bigint);INSERT INTO a (id) VALUES (1); -- this id's value doesn't matterALTER 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'tmatterThere it is. These are similar steps as I'd used to track down a bugthat's now fixed in 11.1.https://www.postgresql.org/message-id/9cb4aa1c-12ba-59c3-fd75-545fa90fb92f%40lab.ntt.co.jpThe bug had to do with foreign key trigger not getting a properrepresentation of the tuple being deleted, considering the newly added column.-- VACUUM FULL ANALYZE a; -- uncomment this to fix the bugAh, VACUUM FULL will rewrite the tuples such that they're not hit by theaforementioned bug.So, if OP can tell that this is what happened in their case too, then 11.1will have fixed the issue.Thanks,Amit
I stumbled upon this issue yesterday, and trying to reduce and pinpointit, I managed to get to this://startCREATE TABLE a ( id bigint);INSERT INTO a (id) VALUES (1); -- this id's value doesn't matterALTER 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'tmatter
-- VACUUM FULL ANALYZE a; -- uncomment this to fix the bug
pgsql-bugs by date:
Соглашаюсь с условиями обработки персональных данных