Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

From: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, 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-28 00:45:00
Message-ID: CADzfLwWLe9tYQZuK9CHTN+rHS4V64wjfhOuJnyXtPSVBhQUmtw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, Álvaro!

Thanks for your review!

> Actually, about this fragment ... if we track these ancestors for all
> indexes, not just the ones that we consider as arbiters, don't we risk
> doing something stupid when a completely unrelated index is being
> reindexed? Namely, also consider that unrelated index as arbiter.

Yes, such a thing may happen. It will not cause any error, because such an
index will be used as artiber only if another compatible index in that same
relation is present.
And additional_arbiters will be incremented.

> I think the lappend_oid(ancestors_seen) should happen inside the
> "if list_member_oid(ancestors)" block instead.

But yes, it is a more clear way. Added to v3.

> I'm also missing a comment for why the use linitial_oid(ancestors) is
> correct. At first I thought we should walk the entire ancestors list,
> and do this dance if any OID there matches the ancestors_seen list. I
> convinced myself that this isn't necessary because the scenario is a
> single table being under REINDEX CONCURRENTLY, so the two indexes would
> have the same root relation (top-most ancestor index). So comparing
> linitial() is correct.

Probably you think linitial() is "root", but it is an immediate parent.
I am not sure I understood you correctly, but I added a comment about it.
And about the opposite race + assert (not sure we need to keep it).

Best regards,
Mikhail.

Attachment Content-Type Size
v3-0001-Fix-duplicate-arbiter-detection-during-REINDEX.patch application/octet-stream 8.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2026-01-28 00:59:25 Re: Extended Statistics set/restore/clear functions.
Previous Message Michael Paquier 2026-01-27 23:51:54 Re: Extended Statistics set/restore/clear functions.