| 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
| 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 |