On Wed, Oct 28, 2026 at 08:14:17AM +0800, Chao Li wrote: > On Oct 28, 2026, at 02:44, Bharath Rupireddy > <[email protected]> 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
signature.asc
Description: PGP signature
