Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 0D3F01337B7A for ; Sat, 29 Jan 2011 12:58:45 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 76036-04 for ; Sat, 29 Jan 2011 16:58:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 3072A1336971 for ; Sat, 29 Jan 2011 12:58:36 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p0TGvtgt012067; Sat, 29 Jan 2011 11:58:35 -0500 (EST) To: "Bradley Holbrook" cc: pgsql-admin@postgresql.org Subject: Re: Drop Schema Error In-reply-to: <00fe01cbbf46$a1c21c20$e5465460$@servillian.ca> References: <00fe01cbbf46$a1c21c20$e5465460$@servillian.ca> Comments: In-reply-to "Bradley Holbrook" message dated "Fri, 28 Jan 2011 15:53:59 -0800" Date: Sat, 29 Jan 2011 11:57:55 -0500 Message-ID: <12066.1296320275@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201101/189 X-Sequence-Number: 36629 "Bradley Holbrook" writes: > DROP SCHEMA "_old_permissions" CASCADE; > NOTICE: drop cascades to 2 other objects > DETAIL: drop cascades to function 17059 > drop cascades to function 17060 > [Err] ERROR: cache lookup failed for function 17060 > What is this trying to tell me? Apparently you've got some dangling references in pg_depend, ie those functions were dropped already but the pg_depend entries for them were not cleaned up. We've heard similar reports before (usually about temp tables not functions, IIRC) but never been able to reproduce them or identify a cause. What PG version is this? Have you done anything funny to that schema or its contents, or had any crashes around the time of manipulating either? As far as cleaning up goes, the thing to do would be to manually delete the relevant pg_depend entries --- for this one, an entry with objid = 17060 is probably what you're looking for. But it would be good to try to figure out how you got into this state first. regards, tom lane