Re: Introducing find_all_inheritors_ordered()

> On Sep 8, 2026, at 07:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.

+1

I can look into if we can prevent concurrent ALTER TABLE ... INHERIT commands from creating cycles at a reasonable cost, and start a separate discussion.

>
> 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.
>

That’s a good point. In the initial version, I tried to avoid touching find_all_inheritors(), which resulted in some duplicate code. In v3, I have refactored the two functions to share the data-gathering and locking code.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/