Re: Crashes on a partition whose concurrent detach never finished

On Mon, Nov 9, 2026 at 6:54 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
>
> 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).

Sorry for not being clear. I meant the pgoutput crash.

IIUC while this is an existing issue, commit fd366065e06 made it
worse. Before the commit, the llast_oid() call on the result of
get_partition_ancestors() in get_rel_sync_entry() was reached only
when publish_via_partition_root = true, but now it's reached
regardless of publish_via_partition_root for FOR ALL TABLES
publications. So decoding a change to a detach-pending partition
crashes the walsender even with the default publish_via_partition_root
= false. In other words, that case works with v18 but no longer with
v19. So I think we should fix it in v19.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com