Re: DROP FUNCTION failure: cache lookup failed for relation X

From: Bruce Momjian <bruce(at)momjian(dot)us>
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 X
Date: 2007-02-01 02:38:36
Message-ID: 200702010238.l112cao08697@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Uh, where are we on this?

---------------------------------------------------------------------------

Tom Lane wrote:
> I wrote:
> > Michael Fuhr <mike(at)fuhr(dot)org> writes:
> >> I've found a situation that causes DROP FUNCTION to fail (tested
> >> in 8.1.6, 8.2.1, and 8.3devel):
> >> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php
>
> > Ugh ... I haven't traced this through in detail, but I'm pretty sure
> > the problem arises from the fact that dependency.c traces through
> > auto/internal dependencies before actually starting to do the deletions
> > (and thus before acquiring locks).
>
> I looked into this a bit more, and found that it's actually a pretty
> general issue with the dependency.c code: we delete objects depending
> on a target object before we delete the target itself. Which is fine,
> except that we don't try to take out any lock on the target object until
> we get to the object-type-specific subroutine that's supposed to delete
> it.
>
> I think we could fix this for tables by acquiring lock on a table at the
> instant it's put into a list for deletion inside dependency.c. That
> would be enough to fix Michael's problem instance, but what of other
> types of objects? There doesn't seem to be anything preventing somebody
> from, say, deleting a function at the same time someone else is creating
> an operator depending on the function. We mostly don't take locks on
> non-table objects while working with them, and for the most part this is
> fairly sane because those objects are defined by a single system catalog
> row anyway: either you see the row or you don't. But this means that
> the depended-on object could be gone by the time you finish adding a
> dependency on it.
>
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-02-01 02:45:27 Re: [pgsql-patches] [HACKERS] [Fwd: Index Advisor]
Previous Message Gavin Sherry 2007-02-01 02:24:41 Re: Data archiving/warehousing idea

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2007-02-01 02:44:48 Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum
Previous Message Koichi Suzuki 2007-02-01 02:07:27 Full page writes improvement