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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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