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)
