Re: pg_dump/restore failure (dependency?) on BF serinus - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: pg_dump/restore failure (dependency?) on BF serinus
Date
Msg-id asOdqbyEtsSoRAlP@alvherre.pgsql
Whole thread
In response to Re: pg_dump/restore failure (dependency?) on BF serinus  (Kirill Reshke <reshkekirill@gmail.com>)
Responses Re: pg_dump/restore failure (dependency?) on BF serinus
List pgsql-hackers
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/



pgsql-hackers by date:

Previous
From: Nisha Moond
Date:
Subject: Re: Show effective xmin in pg_replication_slots when xmin is not set
Next
From: Matthias van de Meent
Date:
Subject: Re: Direct TOAST v2, faster, smaller and no migration needed