Re: [GENERAL] pg.dropped - Mailing list pgsql-hackers

From Filip Rembiałkowski
Subject Re: [GENERAL] pg.dropped
Date
Msg-id 92869e661001080548r39ca0fc9n6a5bc273b279150c@mail.gmail.com
Whole thread Raw
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Streaming replication and triggering failover
Next
From: Fujii Masao
Date:
Subject: Re: ACK from walreceiver to walsender