Fix stale relcache fields for TOAST indexes during REINDEX CONCURRENTLY

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