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/
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 |
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) |