| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | maximilian(dot)chrzan(at)here(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table. |
| Date: | 2025-06-20 11:29:10 |
| Message-ID: | CAFiTN-t0LFgiHgD7DvHZtCxL46X3qdARAmYoLREVizH_YyEn6A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Fri, Jun 20, 2025 at 2:29 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Dilip Kumar <dilipbalaut(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2025-06-20 12:24:20 | BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist |
| Previous Message | Hayato Kuroda (Fujitsu) | 2025-06-20 08:20:50 | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2025-06-20 12:19:57 | Removing rm regress.def |
| Previous Message | Rahila Syed | 2025-06-20 11:23:52 | Re: add function for creating/attaching hash table in DSM registry |