Re: Fix stale relcache fields for TOAST indexes during REINDEX CONCURRENTLY

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, saicharh(at)amazon(dot)com
Subject: Re: Fix stale relcache fields for TOAST indexes during REINDEX CONCURRENTLY
Date: 2026-10-28 16:04:00
Message-ID: CALj2ACWwxTjGiyZgiunzjO3+HRrHG697uagOEvJunSCWqV+-VQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Oct 27, 2026 at 10:57 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Oct 28, 2026 at 10:43:26AM +0900, Michael Paquier wrote:
> > Ah. Good point here. Better to tweak that and remove the dependency
> > on the length. Will look at all that head down..

Thanks both for pointing me to the text_length() optimization.

> I have tested an extra approach where I make the REINDEX wait for
> older snapshots after validating the new index, pointing at the fact
> that these two extra injpoint wakeups should not be required, as much
> as wait_for_point().

Nice, this is better. I think this approach makes the
define-index-before-set-valid injection point redundant. I haven't dug
into it, but maybe reindex-conc-index-built and
reindex-relation-concurrently-before-{swap, set-dead, drop} too, since
they all seem to be before a wait for lockers or older snapshots.

> So I am feeling pretty confident that I got that right. The buildfarm
> will judge, so we'll see. The CI was stable.

BF looks fine so far.

> Anyway, applied the patch down to v14, with the test down to v17.

Thanks for taking care of this.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ethantran 2026-10-28 16:11:20 Review: Price hashed aggregation for hash tables that exceed CPU cache capacity
Previous Message Greg Burd 2026-10-28 16:00:11 Re: Quickselect instead of a heap for ORDER BY ... LIMIT N large bounded sorts