Re: [GENERAL] pg.dropped

Поиск
Список
Период
Сортировка
От Filip Rembiałkowski
Тема Re: [GENERAL] pg.dropped
Дата
Msg-id 92869e661001080548r39ca0fc9n6a5bc273b279150c@mail.gmail.com
обсуждение исходный текст
Список pgsql-hackers
(continued from -general)


W dniu 7 stycznia 2010 22:31 użytkownik Greg Smith <greg@2ndquadrant.com> napisał:
Filip Rembiałkowski wrote:
After dropping a column from table, there is still entry in pg_attribute

filip@la_dev=# select * from pg_attribute where attrelid = (select oid from pg_class where relname='thetable') order by attnum desc limit 1;
-[ RECORD 1 ]-+------------------------------
attrelid      | 4753849
attname       | ........pg.dropped.69........
...
attisdropped  | t

See that last part?  That's what happens when you drop a table--"attisdropped" is set to true.  The server can't just delete the pg_attribute entry altogether for various internal reasons, this is what it does instead.

When should server delete this row? In my case it looks like it's never deleted (it lasts even server restart).
 


And of course this makes my INSERT not working...

There's obviously something wrong here, but the fact that the pg_attribute entry is still there (but marked dropped) is a not a direct cause of your problem.

Thanks, I get it.
 


--
Filip Rembiałkowski
JID,mailto:filip.rembialkowski@gmail.com
http://filip.rembialkowski.net/

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Streaming replication and triggering failover
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: ACK from walreceiver to walsender