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

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.

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/