Re: Crashes on a partition whose concurrent detach never finished

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.

Regards,

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