> On Sep 8, 2026, at 07:38, Tom Lane <[email protected]> wrote: > > Zsolt Parragi <[email protected]> writes: >> On Mon, 07 Sep 2026, Chao Li <[email protected]> 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/
v3-0001-Add-find_all_inheritors_ordered.patch
Description: Binary data
