Re: Crashes on a partition whose concurrent detach never finished

From: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com
Subject: Re: Crashes on a partition whose concurrent detach never finished
Date: 2026-09-03 07:24:54
Message-ID: CABdArM7GwU_k_0A6RkAy4YXZNPdk53ygVHLD=g6Xbsx_BagZZQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

--
Thanks,
Nisha

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2026-09-03 07:33:18 RE: Fix resource leak in FindConflictTuple() retry path
Previous Message Osama Abdul Qader 2026-09-03 07:13:43 Re: REPACK (ANALYZE) within transaction block segfaults