On Sat, Aug 15, 2026 at 10:20 PM Alvaro Herrera <[email protected]> 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.
