Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

From: Hannu Krosing <hannuk(at)google(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Mihail Nikalayeu <mihailnikalayeu(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: 2025-11-28 18:09:03
Message-ID: CAMT0RQR7otO0NOByBffP3=oh=AtR2suTO=yNR6pddp+OMwAO_Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Please also check my (very raw) proposal in the thread "Revisiting
{CREATE INDEX, REINDEX} CONCURRENTLY improvements"

TL;DR - use logical decoding for adding index entries for tuples added
during CIC.

Maybe this also makes the issue with ON CONFLICT UPDATE and REINDEX
CONCURRENTLY go away.

On Fri, Nov 28, 2025 at 6:30 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> Hello,
>
> Here's a slightly different approach for the fix proposed in your 0003.
> I wasn't happy with the idea of opening all indexes twice in
> infer_arbiter_indexes(), so I instead made it collect all Relations from
> those indexes in an initial loop, then process them in the two places
> that wanted them, and we close them all again together. I think this
> also makes the code clearer. We no longer have the "next" goto label to
> close the index at the bottom of the loop, but instead we can just do
> "continue" cleanly.
>
> I also rewrote some comments. I may not have done all the edits I
> wanted, but ran out of time today and I think this is in pretty good
> shape.
>
> I tried under CATCACHE_FORCE_RELEASE and saw no problems.
>
>
> --
> Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2025-11-28 18:17:41 Re: IPC/MultixactCreation on the Standby server
Previous Message Hannu Krosing 2025-11-28 18:05:12 Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements