"James Farrugia" <james.farrugia@xxxxxxxxx> writes: > I wonder whether any of you can help me out with this problem. What PG version is this? > To get vacuum the TOAST object we created a temporary table foo (col1 > char(1)) and assigned its reltoastrelid (up till now set to 0) to > pg_toast_35027430's OID and then vacuumed foo. The plan worked and > immediately age(datfrozenxid) in pg_database reflected a much younger XID. > We then decided to get rid of pg_toast_35027430 by dropping foo. Foo > disappeared but pg_toast_35027430 persisted. Well, yeah, because you didn't create a pg_depend link. We have seen a couple prior reports of toast tables not going away when their parent was dropped, but nobody's been able to create a reproducible case yet. The most likely idea is probably that pg_depend got corrupted somehow, causing the toast table not to get found by DROP. Can you find any rows in pg_depend having objid equal to the OID of pg_toast_35027430? Try reindexing pg_depend and then see if you find any. regards, tom lane
