alter table only ... drop constraint broken in HEAD
| От | Alex Hunsaker |
|---|---|
| Тема | alter table only ... drop constraint broken in HEAD |
| Дата | |
| Msg-id | CAFaPBrRjrZGS26RQ_WFugh=paQV8B=TmJ=ndATWDsbtvxc0LhQ@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: alter table only ... drop constraint broken in HEAD
|
| Список | pgsql-hackers |
tldr: Seems to be broken by http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4da99ea4231e3d8bbf28b666748c1028e7b7d665 : commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665 Author: Robert Haas <rhaas@postgresql.org> Date: Mon Jun 27 10:27:17 2011 -0400 Avoid having two copies of the HOT-chain search logic. Full story: While playing with the non inheritable constraints patch (https://commitfest.postgresql.org/action/patch_view?id=611) I noticed the following sequence was broken: create table colors (c text check (not null)); create table colors_i () inherits (colors); alter table only colors drop constraint colors_check; ERROR: relation 16412 has non-inherited constraint "colors_check" Naturally I assumed it was the patches fault, but after further digging turns out it was not. I bisected it down to the above commit (for those that have not tried git bisect and git bisect run its great for this kind of thing). The basic problem seems to be after we update pg_constraint to decrement inhcount for a child table we call CommandCounterIncrement(); then we fetch the next row from pg_constraint... which happens to be the row we just updated. So we try to decrement it again, only now its at 0 which shouldn't happen so we error out. The simple fix seemed to be to move the CommandCounterIncrement() outside of the while(... systable_getnext()) loop. Im not sure if that's the right thing to-do or if there is some other bug here...
Вложения
В списке pgsql-hackers по дате отправления: