Skip site navigation (1) Skip section navigation (2)

Re: DROP FUNCTION failure: cache lookup failed for relation

From: Richard Troy <rtroy(at)ScienceTools(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Fuhr <mike(at)fuhr(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DROP FUNCTION failure: cache lookup failed for relation
Date: 2007-01-28 20:44:46
Message-ID: Pine.LNX.4.33.0701281238000.30496-100000@denzel.in (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

> It seems a general solution would involve having dependency.c take
> exclusive locks on all types of objects (not only tables) as it scans
> them and decides they need to be deleted later.  And when adding a
> pg_depend entry, we'd need to take a shared lock and then recheck to
> make sure the object still exists.  This would be localized in
> dependency.c, but it still seems like quite a lot of mechanism and
> cycles added to every DDL operation.  And I'm not at all sure that
> we'd not be opening ourselves up to deadlock problems.
>
> I'm a bit tempted to fix only the table case and leave the handling of
> non-table objects as is.  Comments?
>
> 			regards, tom lane

The taking of DDL locks is very unlikely to create a performance problem
for anyone as DML statements typically far outnumber DDL statements.
Further, in my experience, DDL statements are very carefully thought
through and are usually either completely automated by well crafted
programs or are performed by one person at a time - the DBA. I therefore
conclude that any deadlock risk is triflingly small and would be a
self-inflicted circumstance.

Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy(at)ScienceTools(dot)com, http://ScienceTools.com/


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-01-28 21:06:58
Subject: Re: weird buildfarm failures on arm/mipsel and --with-tcl
Previous:From: Neil ConwayDate: 2007-01-28 20:18:49
Subject: Re: UUID patch broke win32

pgsql-patches by date

Next:From: Bruce MomjianDate: 2007-01-28 22:02:24
Subject: Re: [ADMIN] server process (PID xxx) was
Previous:From: Kris JurkaDate: 2007-01-28 18:08:58
Subject: Re: uuid patch 3.0 (8.3devel)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group