I think about revisiting (1) ({CREATE INDEX, REINDEX} CONCURRENTLY improvements) in some lighter way.
Yes, a serious bug was (2) caused by this optimization and now it reverted.
But what about a more safe idea in that direction: 1) add new horizon which ignores PROC_IN_SAFE_IC backends and standbys queries 2) use this horizon for settings LP_DEAD bit in indexes (excluding indexes being built of course)
Index LP_DEAD hints are not used by standby in any way (they are just ignored), also heap scan done by index building does not use them as well.
But, at the same time: 1) index scans will be much faster during index creation or standby reporting queries 2) indexes can keep them fit using different optimizations 3) less WAL due to a huge amount of full pages writes (which caused by tons of LP_DEAD in indexes)
The patch seems more-less easy to implement. Does it worth being implemented? Or to scary?
I hihgly doubt this is worth the additional cognitive overhead of another liveness state, and I think there might be other issues with marking index tuples dead in indexes before the table tuple is dead that I can't think of right now.
I've thought about alternative solutions, too: how about getting a new snapshot every so often?
We don't really care about the liveness of the already-scanned data; the snapshots used for RIC are used only during the scan. C/RIC's relation's lock level means vacuum can't run to clean up dead line items, so as long as we only swap the backend's reported snapshot (thus xmin) while the scan is between pages we should be able to reduce the time C/RIC is the one backend holding back cleanup of old tuples.
