Re: Crashes on a partition whose concurrent detach never finished

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Mihail Nikalayeu <mihailnikalayeu(at)gmail(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, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Crashes on a partition whose concurrent detach never finished
Date: 2026-09-08 05:12:54
Message-ID: CAJpy0uBBKs8cwEMTJpkQm-2QJJDS-ckXm-me+dKxTak3hWAZew@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 8, 2026 at 9:22 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> >
> > > 2. I am also unclear on the intent. When a partition is undergoing
> > > concurrent detach, do we ultimately want to publish its changes or
> > > not?
> > >
> >
> > It depends. For example, if it is ALL TABLES publication then the
> > in-process detach partition should be replicated as an individual
> > table.
>
> Yes, that's what I thought initially, but the test case validates
> otherwise. See the test in patch-001: the publication is for ALL
> TABLES, but the partition being detached is not replicated.
>
> I think this patch focuses on fixing the crash without clarifying the
> intent for various cases: whether to publish or not publish the
> detached partition.
>

I tested it further on my machine. Here are the observations:

1)
FOR ALL TABLES pub:
While DETACH PARTITION ... CONCURRENTLY is in its intermediate state
(inhdetachpending = true), changes made directly to the detached
partition continue to be replicated. This is expected IMO, since the
partition is independently included in an ALL TABLES publication,
regardless of its partition relationship with t1.

<The testcase of patch001 shows otherwise. It needs some analysis to
determine why. This means comment in get_rel_sync_entry in patch001 is
correct, the functionality is as per that comment.>

2)
FOR TABLE root pub:
During the intermediate state of DETACH PARTITION ... CONCURRENTLY,
changes made directly to the partition being detached (t1_part1) are
also replicated, even though t1_part1 is not explicitly listed in
pg_publication_tables and pg_partition_root(t1_part1) already returns
t1_part1. This needs some thought regarding how it should behave.
Should t1_part1 not replicated here? Thoughts?

Once the detach completes, changes to t1_part1 are no longer
replicated through the publication of t1, which appears correct.
~~

Please see attached test-results for details. The behaviour is the
same whether I test patch001 alone or all three combined.

Thanks
Shveta

Attachment Content-Type Size
detach_ptn_tests.txt text/plain 5.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou (Fujitsu) 2026-09-08 05:24:25 RE: Publication DDL can race with a concurrent UPDATE
Previous Message Fujii Masao 2026-09-08 05:11:56 Re: pg_createsubscriber does not check output_plugin_libraries