Re: tablecmds: fix bug where index rebuild loses replica identity on partitions

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, Alberto Piai <alberto(dot)piai(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Subject: Re: tablecmds: fix bug where index rebuild loses replica identity on partitions
Date: 2026-08-27 05:30:24
Message-ID: 40ECB051-C3E4-489A-934D-3D757DBE991D@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Aug 27, 2026, at 05:17, Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
>
> Hi Chao,
>
> Thanks for the update.
>
> > I have addressed them in v15 expect for the hash-table suggestion. I tried using an HTAB, but ran into several build failures.
>
> The v15 changes LGTM. I am fine with leaving the HTAB idea aside. This is
> not a performance critical path in general, so I do not think it is worth
> adding complexity there. After thinking more about it, I can see why it
> could be difficult, especially if we need to track hash state outside of
> IndexStmt. We can still optimize the lookup by scoping an HTAB inside
> DefineIndex(). In that case we would still carry the list in IndexStmt, but
> we could make the lookups within DefineIndex() more efficient with a
> function-scoped HTAB. But, again, not sure it's worth it.
>
> One other point from yesterday remains. We should invoke
> InvokeObjectPostAlterHook() after the CatalogTupleUpdate() in
> SetIndexStatTargets(), and InvokeObjectPostAlterHookArg() after the direct
> pg_index CatalogTupleUpdate() in DefineIndex() inside the
> stmt->idxisclustered || stmt->idxisreplident block.
>
> I think this is the right thing to do because, although we are restoring
> existing values, these are being restored onto a newly created index with a
> new OID.

Sorry for missing this comment. Yes, I agree that it makes sense to call the hook. The two hooks are added to 0001 and 0002 accordingly in v15.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-08-27 05:35:22 Re: tablecmds: fix bug where index rebuild loses replica identity on partitions
Previous Message Bertrand Drouvot 2026-08-27 05:21:16 Re: pgstat: Flush some statistics within running transactions, take 2