On Wed, Nov 11, 2026 at 10:51 AM shveta malik <[email protected]> wrote: > > 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.
I have attached a potential fix for Pg19. It is similar to the fix in 'RelationBuildPublicationDesc'. I have run a few related test-suits on this; I have yet to run 'make check world'. The issue reproduces on HEAD too; the same patch applies and fixes it there. thanks Shveta
0001-PG19-fix-for-get_rel_sync_entry-crash.patch
Description: Binary data
