Hi, I received an off-list report of an "ERROR: missing chunk number x for toast value xxxx in pg_toast_xxxx" during REINDEX CONCURRENTLY.
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. 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. Thoughts? [1] ERROR: missing chunk number 0 for toast value 20810 in pg_toast_20801 -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
v1-0001-Fix-stale-relcache-fields-for-TOAST-indexes-durin.patch
Description: Binary data
