Re: pg_dump/restore failure (dependency?) on BF serinus

On Mon, 5 Oct 2026, 18:19 Álvaro Herrera, <alvherre(at)alvh(dot)no-ip(dot)org> 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/
>