Re: Crashes on a partition whose concurrent detach never finished

On Thu, Sep 3, 2026 at 5:25 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
>
> 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.
> >
>
> While testing another feature patch in the recent past (Except table
> for tables in a schema), I also came across the same issue in
> get_rel_sync_entry(). The issue and testcase are shared at [1]. The
> root cause is the same as described here.
>

My thread about a get_partition_root function is related to this too [1].

> I tested patch v1-0001 against my reproducer, and it fixes the issue for me.
>
> Overall, the fixes in all three places look good to me. Just a small
> nit: patch-001's pgoutput.c requires pgindent run.
>
> [1] https://www.postgresql.org/message-id/CABdArM64ZSat%3DdB094U8OCBzp1m8_Y85m6T%2BxPEgpLVJb60_rA%40mail.gmail.com
>

======
[1] https://www.postgresql.org/message-id/flat/CAHut%2BPtc73UpWSn4teMyMxQoHwGJjRwhWiu%3DhGJqAj5k2AOXEw%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia