On Mon, 5 Oct 2026, 18:19 Álvaro Herrera, <[email protected]> wrote:
> On 2026-Oct-05, Kirill Reshke wrote: > > > 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. > > No other tests fail after this change either. > > -- > Álvaro Herrera 48°01'N 7°57'E — > https://www.EnterpriseDB.com/ >
