Re: Introducing find_all_inheritors_ordered()

Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> writes:
> On Mon, 07 Sep 2026, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> My understanding is that PG doesn’t intend to support cyclic inheritance. The code explicitly rejects it:

> To me it seems like that it discourages it and tries to prevent it
> where it's possible to do so with reasonable effort, but it ends up
> trying to support it because it's a valid scenario that can happen in
> some workloads (as long as that also doesn't require too much effort).

Why is it a valid scenario, and how would we reach it? It's going to
cause tons of problems if it can happen, so I'd rather put effort into
blocking it than making some parts of the system cope.

I have a different concern about the patch as it stands: the
data-gathering part is unnecessarily duplicative of
find_all_inheritors. It does its best to look like it's doing
something different, but actually it computes exactly the same list
of relation OIDs and the same number-of-parents data. And indeed
it had better be doing the same things in the same order, because
otherwise we'd be risking deadlock failures instead of simple
blocking when two processes are acquiring exclusive locks on
overlapping inheritance trees. (Note the comment about "we need to be
sure all backends lock children in the same order to avoid needless
deadlocks" in find_inheritance_children.) I don't like having two
independent implementations that are invisibly tied like that: if
they diverge, we might not notice until somebody makes a bug report
and somebody else figures out what's causing the deadlock. So IMO
those two functions need to be revised to use a common data-gathering
step.

regards, tom lane