Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.

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

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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