Re: Crashes on a partition whose concurrent detach never finished

On Wed, Nov 11, 2026 at 1:05 PM Zhijie Hou <houzhijie22(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Sun, Sep27, 2026 at 10:26 PM Mihail Nikalayeu wrote:
> > 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.
>
> Since we are considering whether to push 0001 first, I reviewed it and
> have few suggestions:
>
> 1. We can remove the am_partition variable completely and simply check
> "ancestors" in the subsequent code, to be consistent with
> RelationBuildPublicationDesc.
>
> 2. The test can be simplified to cover only the decoding crash (since
> the subscriber side is not touched by this patch), which saves buildfarm
> test time. In addition, we can move the test into the existing isolation
> test to speed it up further.
>
> I have attached a top-up patch for 0001 with these changes. Feel free to
> merge it if it looks good.

I agree with the changes. Few concerns:

It would be better to show in the additional steps that
pg_inherits.inhdetachpending is true before we actually try
pg_logical_slot_get_binary_changes.

Also I feel it would make more sense to create-pub with default
publish_via_partition_root rather than publish_via_partition_root=true
for PG19's testcase.

thanks
Shveta