> On Sep 8, 2026, at 06:16, Zsolt Parragi <[email protected]> wrote:
>
> 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).
I think an important problem is that, in your earlier example, two users
independently execute ALTER TABLE … INHERIT, but the commands together create
an inheritance cycle without either user being notified. Even if PG currently
tolerates this, I think preventing it would be preferable.
As Tom pointed out, cycles can also cause problems elsewhere in the system. So
I agree that we should investigate whether we can prevent their creation at a
reasonable cost.
>
>> A cycle can cause it to exceed the stack depth limit, so it is reasonable to
>> fail the command when a cycle is detected.
>
> Or it might succeed in other cases.
>
> Here's a repro with an isolation test. Perm 1 fails on master, works
> with the patch. Perm 2 works on master, fails with the patch.
> We could improve this by only using the new function in the enforced
> direction, I don't have a better idea currently. With that, the
> patched behavior would be the same as on master.
>
This is a valid point. ENFORCED doesn’t need to check parents’ enforceability,
so we can still use find_all_inheritors() to tolerate potential cycles and use
find_all_inheritors_ordered() only for NOT ENFORCED. This preserves master’s
success/failure outcomes in your test, while replacing the stack-depth error
with an explicit cycle error. I have updated the code in v3.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
