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

From Álvaro Herrera
Subject Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Date
Msg-id 202601261855.btsbm3vgwpos@alvherre.pgsql
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 2026-Jan-25, Mihail Nikalayeu wrote:

> Hello, Álvaro!
> 
> Fixes are in attachment. I think the comment message and comments are good
> enough to explain the changes.

Great, many thanks for this.  The commit message looks quite good, but I
decided to rewrite the comment in the code.  What do you think of this?

(There's also a typo fix for one of the previous commits)

> Also, the second commit adds syscache for pg_inherites. I am not very
> confident with it, but it feels correct to me.

Hmm, I think a syscache on (inhrelid, inhseqno) is a bit weird.  This
might be okay, but I'm not sure, and I don't think we absolutely need
this right now.  That is to say, I'm not rejecting this, but I'm not
going to pursue getting it pushed for now.

> Another approach - put information about parents into [relcache] - I
> can rebuild the patch that way.

I think that change would be a larger revamp that I definitely don't
want to touch at this time.

> Also, for the first commit it is possible to create a batched version of
> get_partition_ancestors (with the same snapshot for multiple indexes).

Yeah, I've had such thoughts too, but I'd rather fix the bug in a
reasonably non invasive way (which perhaps we can consider backpatching
in some not-too-distant future); major rearchitecting like that can
happen later without pressure.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables
Next
From: Masahiko Sawada
Date:
Subject: Re: Initial COPY of Logical Replication is too slow