On Wed, Nov 11, 2026 at 2:16 AM Masahiko Sawada <[email protected]> wrote:
>
> On Mon, Nov 9, 2026 at 6:54 PM Nisha Moond <[email protected]> wrote:
> >
> > On Tue, Nov 10, 2026 at 12:40 AM Masahiko Sawada <[email protected]>
> > wrote:
> > >
> > > On Sun, Sep 27, 2026 at 7:27 AM Mihail Nikalayeu
> > > <[email protected]> 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.
Yes, I reproduced the crash on PG 19 using the attached test. I
verified that it works on PG18.
> 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
CREATE TABLE parent (a int) PARTITION BY RANGE (a);
CREATE TABLE part1 PARTITION OF parent FOR VALUES FROM (0) TO (100);
CREATE PUBLICATION pub FOR ALL TABLES; -- default publish_via_partition_root
= false
SELECT pg_create_logical_replication_slot('slot', 'pgoutput');
-- Session 1: hold a snapshot so DETACH CONCURRENTLY has to wait
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) FROM parent;
-- Session 2: start the detach and let it time out, leaving part1 detach-pending
SET statement_timeout = '1s';
ALTER TABLE parent DETACH PARTITION part1 CONCURRENTLY;
-- ERROR: canceling statement due to statement timeout
-- Session 1:
COMMIT;
-- Any session:
SELECT inhdetachpending FROM pg_inherits WHERE inhrelid = 'part1'::regclass;
-- t
INSERT INTO part1 VALUES (1);
SELECT count(*) FROM pg_logical_slot_get_binary_changes('slot', NULL, NULL,
'proto_version', '4', 'publication_names', 'pub');
