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 CADzfLwVtnR1AqBxUGnyddRwE3V3=fPqsLvygpRTscVE4AENjBA@mail.gmail.com
Whole thread Raw
In response to Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY  (Mihail Nikalayeu <mihailnikalayeu@gmail.com>)
Responses Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
List pgsql-hackers
Hello!

On Mon, Jan 19, 2026 at 11:59 PM Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:
>It fails with the state then we have 2 indexes (leaf_part_rri->ri_NumIndices=2) and EACH OF them have an ancestor. So, both of them are added as arbiters.

I found the cause of the issue.

As Álvaro mentioned early - get_partition_ancestors does not uses any caches, so, each scan invalidates catalog snapshot [0].

In our case for first index - snapshot sees data before index_concurrently_swap committed, but for second one - after. It is rear case, but possible.

It is not a new problem (caused by that patch set), the same may happen before, but in little bit different way:

1) some index selected (old one) for plan
2) index_concurrently_swap committed
3) get_partition_ancestors uses new catalog snapshot and sees 0 ancestors for the index - the same error

So, test found the issue - great. I'll prepare the fix and additonal test later this week.

pgsql-hackers by date:

Previous
From: Mihail Nikalayeu
Date:
Subject: Re: Race conditions in logical decoding
Next
From: Michael Paquier
Date:
Subject: Re: Having problems generating a code coverage report