Added to TODO:
* Increase locking when DROPing objects so dependent objects cannot
get dropped while the DROP operation is happening
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php
---
Tom Lane wrot
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Uh, where are we on this?
Still in the think-about-it mode, personally ... my proposed fix is
certainly much too invasive to consider back-patching, so unless someone
comes up with a way-simpler idea, it's 8.3 material at best ...
Uh, where are we on this?
---
Tom Lane wrote:
> I wrote:
> > Michael Fuhr <[EMAIL PROTECTED]> writes:
> >> I've found a situation that causes DROP FUNCTION to fail (tested
> >> in 8.1.6, 8.2.1, and 8.3devel):
> >> http://arc
> 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
I wrote:
> Michael Fuhr <[EMAIL PROTECTED]> 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
> t
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I've found a situation that causes DROP FUNCTION to fail (tested
> in 8.1.6, 8.2.1, and 8.3devel):
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 depende
