> x4m (Andrey) suggest this > > diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c > --- a/src/backend/commands/tablecmds.c > +++ b/src/backend/commands/tablecmds.c > @@ -22618,7 +22618,12 @@ validatePartitionedIndex(Relation partedIdx, > Relation partedTbl) > validatePartitionedIndex(parentIdx, parentTbl); > > - relation_close(parentIdx, AccessExclusiveLock); > - relation_close(parentTbl, AccessExclusiveLock); > + /* > + * Keep these locks until commit, so another validator cannot miss > + * our uncommitted changes to a descendant's indisvalid flag and leave > + * the parent index invalid. > + */ > + relation_close(parentIdx, NoLock); > + relation_close(parentTbl, NoLock); > } > }
Hmm, yeah, I think this is a plausible fix. This code is all from 8b08f7d4820f and I can't remember if I had any rationale for releasing the lock early after potentially doing a DDL change in the affected parent table. This is probably just a thinko.
Thanks for taking a look, LGTM then? I can send thus diff as .patch file if you need one.
AI-generated isolation test is too specific, reproducing this exact issue, I don't think we need to include it. It doesn't provide usefull coverage much. If we decide to nevertheless have test here - tell me, I will remove AI bloat from spec. I didn't have much time to do a legwork here yet.
The reproducer script as given didn't fail very frequently for me -- just 1 out of 180 tries (i.e. I ran it thrice and had just one failure in total). However, I can make it fail almost 50% of the time by adding a pg_usleep(50*1000) immediately below these two relation_close(, AEL) calls; and then when I change them to retain the lock, I see no further failures.
