| From: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |
| Date: | 2026-01-22 00:40:47 |
| Message-ID: | CADzfLwVtnR1AqBxUGnyddRwE3V3=fPqsLvygpRTscVE4AENjBA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello!
On Mon, Jan 19, 2026 at 11:59 PM Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)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.
Mikhail.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-01-22 00:48:35 | Re: Having problems generating a code coverage report |
| Previous Message | Mihail Nikalayeu | 2026-01-22 00:24:43 | Re: Race conditions in logical decoding |