Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 58BCC1337B4F for ; Mon, 31 Jan 2011 14:10:02 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 18481-01 for ; Mon, 31 Jan 2011 18:09:54 +0000 (UTC) X-Greylist: delayed 00:09:47.045855 by SQLgrey-1.7.6 Received: from mail.shawcable.com (shawmail.shawcable.com [64.59.128.220]) by mail.postgresql.org (Postfix) with ESMTP id EAB571336FA7 for ; Mon, 31 Jan 2011 14:09:53 -0400 (AST) Received: from bpd2mi1no-svcs.prod.shawcable.com ([10.0.184.120]) by bpd2mo1no-ssvc.prod.shawcable.com with ESMTP; 31 Jan 2011 11:00:04 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=rhzBfl3TH6jSClqh7E8qe//hARbvbzCI0ETuu7/2kJU= c=1 sm=1 a=BLceEmwcHowA:10 a=rFBdEGy9vS/m0A3AhxL8nA==:17 a=pGLkceISAAAA:8 a=epTmVMiNAAAA:8 a=0RanPRUr-sOKZ68TYTsA:9 a=iFsVeCVgTdbY1udnLIUA:7 a=SEi_a0x4TDOYQ2e7Dmnov9ay88IA:4 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=YObXiYvaVLwA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=R8MTGjiPr9qfZkGvTsUA:9 a=j85vBWOrg1EIUj1KFDwA:7 a=gDlmDjQ-uGNOIMEgeVuNNjWc52kA:4 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-IronPort-AV: E=Sophos;i="4.60,405,1291618800"; d="scan'208,217";a="499389141" Received: from unknown (HELO bpd2mi1no-cmts.prod.shawcable.com) ([192.168.183.120]) by bpd2mi1no-cmts.prod.shawcable.com with ESMTP; 31 Jan 2011 11:00:03 -0700 X-reinject: true Received: from unknown (HELO BradleyHolbrook) ([24.67.39.150]) by bpd2mi1no-dmz.prod.shawcable.com with ESMTP; 31 Jan 2011 11:00:03 -0700 From: "Bradley Holbrook" To: =?UTF-8?Q?'Viktor_Bojovi=C4=87'?= , "'Tom Lane'" Cc: References: <00fe01cbbf46$a1c21c20$e5465460$@servillian.ca> <12066.1296320275@sss.pgh.pa.us> In-Reply-To: Subject: Re: Drop Schema Error Date: Mon, 31 Jan 2011 10:00:03 -0800 Message-ID: <00d201cbc170$af9c5ff0$0ed51fd0$@servillian.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01CBC12D.A17C7B50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHmigR+4celrkQEgv9mn7NuZnsPEwJkcVOtAnxGcHqTjsd9MA== Content-Language: en-ca X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201101/196 X-Sequence-Number: 36636 This is a multipart message in MIME format. ------=_NextPart_000_00D3_01CBC12D.A17C7B50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Worked like a charm, thanks Tom and Viktor. =20 I=E2=80=99m using version 8.4.5 64bit CentOs Linux =20 I renamed the schema from permissions to _old_permissions and I believe = this caused the error. =20 =20 From: Viktor Bojovi=C4=87 [mailto:viktor.bojovic@gmail.com]=20 Sent: January-29-11 11:16 AM To: Tom Lane Cc: Bradley Holbrook; pgsql-admin@postgresql.org Subject: Re: [ADMIN] Drop Schema Error =20 =20 =20 On Sat, Jan 29, 2011 at 5:57 PM, Tom Lane wrote: "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 =3D 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 -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin =20 i had that problem when renaming schema which had already objects = inside. functions inside that schema had references to objects inside that = schema. some functions still had reference to old schema name. so i renamed it again to drop those objects. It was 8.3.13 or prior version @ 32bit debian linux . --=20 --------------------------------------- Viktor Bojovi=C4=87 --------------------------------------- Wherever I go, Murphy goes with me ------=_NextPart_000_00D3_01CBC12D.A17C7B50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Worked like a = charm, thanks Tom and Viktor.

 

I=E2=80=99m = using version 8.4.5 64bit CentOs Linux

 

I renamed the = schema from permissions to _old_permissions and I believe this = caused the error.

 

 

From:= Viktor = Bojovi=C4=87 [mailto:viktor.bojovic@gmail.com]
Sent: = January-29-11 11:16 AM
To: Tom Lane
Cc: Bradley = Holbrook; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Drop = Schema Error

 

 

 

On Sat, = Jan 29, 2011 at 5:57 PM, Tom Lane <tgl@sss.pgh.pa.us> = wrote:

"Bradley = Holbrook" <operations_bradley@servi= llian.ca> 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 =3D
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

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org= )
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

 

i had that problem when renaming schema which had = already objects inside.

functions inside that schema  had references to = objects inside that schema.

some functions still had reference to old schema = name.

so i renamed it = again to drop those objects.

It was 8.3.13 or prior version @ 32bit debian linux =  .



-- =
---------------------------------------
Viktor = Bojovi=C4=87
---------------------------------------
Wherever I = go, Murphy goes with me

------=_NextPart_000_00D3_01CBC12D.A17C7B50--