Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table. - Mailing list pgsql-bugs
From | Tom Lane |
---|---|
Subject | Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table. |
Date | |
Msg-id | 1457083.1750352266@sss.pgh.pa.us Whole thread Raw |
In response to | Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table. (Dilip Kumar <dilipbalaut@gmail.com>) |
List | pgsql-bugs |
Dilip Kumar <dilipbalaut@gmail.com> writes: > On Wed, Jun 18, 2025 at 10:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I experimented with the attached, which borrows a couple of ideas >> from 3db61db48 to produce names like "parent_index_2" when cloning >> indexes. While it should help with the immediate problem, I'm not >> sure if this is acceptable, because there are a *lot* of ensuing >> changes in the regression tests, many more than 3db61db48 caused. > 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. A different approach that we could take --- possibly alongside doing the above --- is to try to remove the race condition between two sessions choosing the same index name. It doesn't look practical to close the race window completely, but it's quite simple to make it a whole lot shorter. If we check for a conflicting relation name using SnapshotDirty instead of only looking for committed pg_class rows, then the window is little more than the time needed to insert the index's pg_class row, rather than being the whole time needed to build the index. (The fact that the OP is working with terabyte-sized tables is what's making this so bad for him.) In the attached draft I only bothered to change the initial probe for a conflicting pg_class entry. We could go further and apply the same idea in ConstraintNameExists(), but I'm not sure it's worth the trouble. regards, tom lane diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c index c3ec2076a52..f2898fee5fc 100644 --- a/src/backend/commands/indexcmds.c +++ b/src/backend/commands/indexcmds.c @@ -2592,7 +2592,9 @@ makeObjectName(const char *name1, const char *name2, const char *label) * constraint names.) * * Note: it is theoretically possible to get a collision anyway, if someone - * else chooses the same name concurrently. This is fairly unlikely to be + * else chooses the same name concurrently. We shorten the race condition + * window by checking for conflicting relations using SnapshotDirty, but + * that doesn't close the window entirely. This is fairly unlikely to be * a problem in practice, especially if one is holding an exclusive lock on * the relation identified by name1. However, if choosing multiple names * within a single command, you'd better create the new object and do @@ -2608,15 +2610,45 @@ ChooseRelationName(const char *name1, const char *name2, int pass = 0; char *relname = NULL; char modlabel[NAMEDATALEN]; + SnapshotData SnapshotDirty; + Relation pgclassrel; + + /* prepare to search pg_class with a dirty snapshot */ + InitDirtySnapshot(SnapshotDirty); + pgclassrel = table_open(RelationRelationId, AccessShareLock); /* try the unmodified label first */ strlcpy(modlabel, label, sizeof(modlabel)); for (;;) { + ScanKeyData key[2]; + SysScanDesc scan; + bool collides; + relname = makeObjectName(name1, name2, modlabel); - if (!OidIsValid(get_relname_relid(relname, namespaceid))) + /* is there any conflicting relation name? */ + ScanKeyInit(&key[0], + Anum_pg_class_relname, + BTEqualStrategyNumber, F_NAMEEQ, + CStringGetDatum(relname)); + ScanKeyInit(&key[1], + Anum_pg_class_relnamespace, + BTEqualStrategyNumber, F_OIDEQ, + ObjectIdGetDatum(namespaceid)); + + scan = systable_beginscan(pgclassrel, ClassNameNspIndexId, + true /* indexOK */ , + &SnapshotDirty, + 2, key); + + collides = HeapTupleIsValid(systable_getnext(scan)); + + systable_endscan(scan); + + /* break out of loop if no conflict */ + if (!collides) { if (!isconstraint || !ConstraintNameExists(relname, namespaceid)) @@ -2628,6 +2660,8 @@ ChooseRelationName(const char *name1, const char *name2, snprintf(modlabel, sizeof(modlabel), "%s%d", label, ++pass); } + table_close(pgclassrel, AccessShareLock); + return relname; }
pgsql-bugs by date: