Re: DROP FUNCTION failure: cache lookup failed for relation - Mailing list pgsql-hackers

From Richard Troy
Subject Re: DROP FUNCTION failure: cache lookup failed for relation
Date
Msg-id Pine.LNX.4.33.0701281238000.30496-100000@denzel.in
Whole thread Raw
In response to Re: DROP FUNCTION failure: cache lookup failed for relation X  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> 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@ScienceTools.com, http://ScienceTools.com/



pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: UUID patch broke win32
Next
From: Tom Lane
Date:
Subject: Re: weird buildfarm failures on arm/mipsel and --with-tcl