Re: Assertion failure with inherited column mappings and dropped columns
От | Tom Lane |
---|---|
Тема | Re: Assertion failure with inherited column mappings and dropped columns |
Дата | |
Msg-id | 6044.1184264249@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Assertion failure with inherited column mappings and dropped columns (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes: > I got this assertion failure today: > postgres=# create table foo (i integer); > CREATE TABLE > postgres=# alter table foo add j integer; > ALTER TABLE > postgres=# alter table foo drop j; > ALTER TABLE > postgres=# create table foo2 () inherits (foo); > CREATE TABLE > postgres=# explain analyze select * from foo; > server closed the connection unexpectedly Nifty. > I think there isn't actually a bug here except that the assertions are > incorrect. Everything else in the function looks ok. In the light of this example, the Assert on new_max_attr is clearly wrong. It always was redundant with the ones inside the first loop anyway. I think the Assert on new_min_attr is still OK though, and in fact necessary to protect against an array bounds violation in the second loop. That Assert is essentially saying that "if the parent table has OIDs then the child must too", which we do enforce. Will patch in HEAD and 8.2 --- this code doesn't exist before 8.2. regards, tom lane
В списке pgsql-hackers по дате отправления: