Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Mihail Nikalayeu
Subject Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Date
Msg-id CADzfLwXLcyEfmQx9FrdVQ-r589YTQsbK04gpNk5HP4XgMDb=Tg@mail.gmail.com
Whole thread Raw
In response to Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY  (Álvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
Hello!

On Sun, Dec 7, 2025 at 10:07 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> I'd rather consider the idea of avoiding indexes marked !indisvalid on
> partitioned tables as arbiter lists ... but then we need to verify the
> scenario where there is one, and INSERT ON CONFLICT runs concurrently
> with ALTER INDEX ATTACH PARTITION for the last partition lacking the
> index (which is the point where the index is marked indisvalid on the
> partitioned table).  There may not be a problem with that, because we
> grab AccessExclusiveLock on the index partition, so no query can be
> running concurrently ... unless the INSERT is targeting a partition
> other than the one where the index is being attached.  (On the
> partitioned table and index, we only have ShareUpdateExclusiveLock).

For my taste it feels too complicated for such a case.

What is about changing the logic of this check to the next:
For each valid index used as arbiter in a partitioned table we need to
have a valid in particular partition (but it is okay to also have an
"ready"-only as additional).

If some of the arbiters is invalid in the partitioned table (but we
have valid compatible in any case) - it is okay. We just have to have
an appropriate "companion" for every valid arbiter.

Such a check looks correct to me, at least at the very end of the weekend.

Thanks,
Mikhail.



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Fix incorrect comments in tuplesort.c
Next
From: Peter Geoghegan
Date:
Subject: Re: Moving _bt_readpage and _bt_checkkeys into a new .c file