Rod Taylor <rbt@zort.ca> writes:
>> BTW, there were a number of places where it seemed that you were trying
>> to avoid creating circular dependencies --- is there a problem with
>> doing that? I think it's a situation that we will have to be able to
>> cope with.
> Yeah. Circular dependencies right now cause a never ending loop when
> dropping them. I tried reversing the order in dependDelete (move calls
> to self to the end) but that caused lots of problems with items
> expecting. It really needs to keep a list of already found dependencies
> and not attempt to drop them again.
I was thinking that the arrangement you have with triggering drops
partway through a drop of another object is inherently unsafe: first,
because it doesn't work for circular dependencies, and second because
CommandCounterIncrement partway through a drop of a complex object like
a table is not a good idea. The CCI might trigger a relcache reload
attempt, and if you have inconsistent state in the system tables (say,
number of triggers or attributes different from what the pg_class row
says to expect) then the relcache routines will elog.
I am thinking that the correct approach is:
1. Drop an object.
2. CommandCounterIncrement.
3. Scan pg_depend for dependency records. For each one found, if
the referencing object still exists then delete it (via a recursive
performance of this same procedure). In any case delete the
dependency record.
Because of the CCI, the object deletion will be visible during the
step-3 scan, and so any recursive invocation will see the original
object as no longer existing, should it happen to follow a dependency
loop back to the original object. If we error out anyplace, then the
whole thing rolls back anyhow.
This will not work for "internal" structure of a table, like the
trigger -> tgrelid dependency that you wanted to use to replace
RelationRemoveTriggers, but I wasn't thrilled with that application
of pg_depend anyway. I will be satisfied with using it to handle
cascaded drops of quasi-independent objects.
>> Nah, I can hack it up myself easily enough; I've already identified a
>> bunch of smaller changes to make (coding style issues mainly).
> If you don't mind sending me back a patch with all of the changes when
> complete, I'd appreciate it.
Will do.
regards, tom lane
