Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.
От | Dilip Kumar |
---|---|
Тема | Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table. |
Дата | |
Msg-id | CAFiTN-t0LFgiHgD7DvHZtCxL46X3qdARAmYoLREVizH_YyEn6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Fri, Jun 20, 2025 at 2:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Dilip Kumar <dilipbalaut@gmail.com> writes: > > I haven't reviewed the patch itself, but I like the idea. We're now > > consistently using the parent index name for partitioned indexes, > > whether they're named or unnamed indexes. That looks like a great > > improvement. And I think including the partition number of each level > > in the index name significantly enhances its clarity, especially > > within a multi-level partition hierarchy. > > Since people seem to think this might be a good way to proceed, > I spent some effort on cleaning up the regression test changes. > > While doing that, I decided that applying this behavioral change to > CREATE TABLE LIKE (the original user of generateClonedIndexStmt) > might not be such a hot idea: the regression test changes that > that induced felt less natural than the ones involving partitioned > indexes. Another practical reason is that all the calls for > partitioned indexes will call DefineIndex immediately, so the > race-condition window for some other session to claim the same > index name is barely wider than it was before. But in CREATE TABLE > LIKE, there's considerably more delay, and I think it might even > be possible to construct counterexamples where our own process > could try to create two identically-named indexes if we try to > nail down the index name in generateClonedIndexStmt. > > So that leads me to the attached. The patch LGTM Excluding CREATE TABLE LIKE > reduces the number of regression-test changes a little, but > there's still a lot of them, implying this is a nontrivial > behavioral change for users. So I feel like this is not > something to squeeze into v18 post-beta-1. I'm thinking it'd > be appropriate for v19 instead. (We could perhaps back-patch > the other SnapshotDirty patch to ameliorate the problem in the > back branches.) Yes, that makes sense to apply in v19 because of user visible behavior changes in index names. I agree the SnapshotDirty patch can give relief for this case for back branches. -- Regards, Dilip Kumar Google
В списке pgsql-bugs по дате отправления: