Re: Crashes on a partition whose concurrent detach never finished

On 2026-Aug-15, Mihail Nikalayeu wrote:

> I was working on stress-suite and discovered a few crashes caused
> mainly by the same issue.
>
> DETACH PARTITION ... CONCURRENTLY marks the partition and commits, and
> only then waits. If that wait is interrupted the mark remains.
> Only PARTITION ... FINALIZE clears it. Reaching this needs no race,
> and the state outlives the command that made it.
>
> In that state pg_class still says relispartition, while
> get_partition_ancestors() already reports nothing.

Interesting, thanks for the testing and for the patches. As far as
backpatchable fixes these look okay to me in a quick glance, and unless
something else comes up, I'll try to get them pushed and backpatched
next week.

However, it can be argued (esp. due to the new bug in 19) that the
choices I made for concurrent detach lead to a system that's far too
brittle, and we should improve it -- for example, maybe it makes more
sense to have get_partition_ancestor() take a boolean parameter to
indicate whether to scan past an in-detach partition or not, as
suggested in the comment in 0002, so that the developer has to make a
conscious decision regarding that condition. That would probably lead
to better code and less room for future bugs.

> Patches are attached, one for each place; each includes a test that
> reproduces the crash.

This is great, thanks.

Please note I have updated my email address. The old one will still
work indefinitely, but I avoid it as much as I am able.

Regards

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"People get annoyed when you try to debug them." (Larry Wall)