Re: Crashes on a partition whose concurrent detach never finished

On Sat, Aug 15, 2026 at 10:20 PM Alvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> 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.
>

Are you planning to look into it? BTW, I see that there is an open
item for PG19 due to v1-0003. So we need to decide what we should do
with this? IIUC, this is a general problem at various places in code
(three pointed by Mihail with test cases and one pointed by Shveta
without a test case). So, we could consider it a bug due to the
behavior of get_partition_ancestors() and deal at all places together
without first trying to close it for PG-19 in which case this should
be moved to the "Older bugs affecting stable branches" section. OTOH,
if you are planning to deal with the reported cases sooner then anyway
PG-19 items will be closed. Will it be helpful if I start dealing with
a few of these, especially 0001 and 0003 provided we agree that API
change could be done as a separate HEAD-only patch?

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

Yes, we can probably consider doing that though for HEAD branch as it
changes the exposed interface.

--
With Regards,
Amit Kapila.