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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(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 01:43:26
Message-ID: auFTPhXtWKXLw1XK@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 28, 2026 at 08:14:17AM +0800, Chao Li wrote:
> On Oct 28, 2026, at 02:44, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>> After the concurrent index rebuild marked the new index ready for
>> inserts, the backend that kept the TOAST indexes (both new and old)
>> open for inserts doesn't reload the new TOAST index entry as part of
>> the invalidation message processing. This leaves the new index not
>> ready for inserts in that backend's relcache, making the chunks miss
>> in the new index. This later shows up as the [1] when the value is
>> read.

This strikes me as a good find. The TOAST values are in the table,
and we miss them in the index. A rebuild of the TOAST index would
resolve the issue, but requiring again a REINDEX after a CONCURRENTLY
one defeats the purpose of the latter if we require the former because
of some silent corruption.

>> Please find the attached patch that allows the TOAST indexes also to
>> re-read the pg_index row and reload the relcache fields in
>> RelationReloadIndexInfo(). Note that this change also reloads the
>> relcache fields for the TOAST indexes of the logical replication
>> conflict log tables, which seems fine IMO.
>>
>> I think this needs to be back-patched to all the supported branches.
>> The check in RelationReloadIndexInfo() was introduced in 8ec943856a4,
>> and the issue was uncovered by 5dc92b844e68, which added REINDEX
>> CONCURRENTLY.

Back when I worked on RIC, I've been heavily relying on the assumption
that we can safely rely on the facilities of CIC for it, so the blame
is on 5dc92b844e68, not really 8ec943856a4. Plop, my fault by
default.

It's good that you have been able to dig out a test, re-using some of
the existing injpoints in the tree.

> For single-byte encodings, length(val) won't actually fetch the
> TOAST values, so the test won't detect missing TOAST chunks.

Ah. Good point here. Better to tweak that and remove the dependency
on the length. Will look at all that head down..
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sho Ito 2026-10-28 02:00:16 Re: [PATCH] Fix whole-row type errors in postgres_fdw UPDATE joins
Previous Message shihao zhong 2026-10-28 01:38:38 Re: [PATCH] add missed tests for gist index