Re: Crashes on a partition whose concurrent detach never finished

From: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, "ashutosh(dot)bapat(dot)oss(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-11-10 02:54:31
Message-ID: CABdArM4jL477awfHnr9sOvmmzR9_0cWO7wMCgVwJxX2LmQ-+yw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 10, 2026 at 12:40 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Sun, Sep 27, 2026 at 7:27 AM Mihail Nikalayeu
> <mihailnikalayeu(at)gmail(dot)com> wrote:
> >
> > Hello, everyone!
> >
> > Thanks to Amit for pushing, and to others for new findings and reviews.
> >
> > Attached is v2 of the remaining fixes, rebased on master and
> > registered in the commitfest as [3] for tracking purposes.
> >
> > I tried to combine everything into the series. It is mostly
> > AI-generated, but I still think structuring everything is helpful
> > anyway.
> >
> > The rule throughout is that a partition pending detach is published as
> > a standalone table, as it will be after FINALIZE; publishing it via
> > the former root would cause the divergence Nisha described in [1].
> >
> > 0001 (pgoutput crash): The test comment Shveta asked about was
> > misleading; it's fixed. pgindent-clean applied.
> >
> > 0002 (identity sequence) gains a new test: an insert into a leaf under
> > a partition pending detach still finds the root's sequence.
> >
> > 0003 is Zsolt's fix for the inconsistency Shveta pointed out:
> > pg_get_publication_tables() now lists a partition with no active
> > ancestors, so REFRESH PUBLICATION can pick it up before FINALIZE.
> >
> > Tests moved to 100_bugs.pl to reuse infra from 0001 (AI-generated).
> >
> > The commit message now also says, as Nisha found in [2], that the full
> > list has been affected since 14, while the targeted lookup only exists
> > in 19.
> >
> > 0004 is Shveta's invalidation, which I (mostly AI) finished up a bit.
> > It also invalidates the descendants of a partitioned partition, as
> > Nisha suggested in [1], and locks them with AccessShareLock.
>
> I ran into this issue today. I think it's not fixed on v19 yet and
> should be added to the open item so as not to miss it.
>

Hi Sawada-san,

Could you please clarify which issue you are referring to here?

IIUC, the only open item for PG19 is the
is_table_publishable_in_publication() related issue, details shared in
point #2 at [1]. The patch v2-0003 shared by Mihail at [2] should
address this.

The other pending issue is the pgoutput crash, which is an existing
code issue (since pg14).

[1] https://www.postgresql.org/message-id/CABdArM7Bc7SZPSHk5uT-yA6%3DDYVFW-Os4noB6CANH6GQw9rvew%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CADzfLwU97r3QC5oZDeVcWvcvXhNy9VnoFNDVHw%2BERg_DEG4%3DFQ%40mail.gmail.com

--
Thanks,
Nisha

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-11-10 02:57:29 Re: Proposal: Conflict log history table for Logical Replication
Previous Message shihao zhong 2026-11-10 02:51:13 Re: Fix cumulative WAL statistics double-counting from parallel workers