It is noted in the post, I'll repeat it to be clear:<p>This corruption can only occur _during_ a (re)index with CONCURRENTLY specified, on rows that are modified during the reindex operation, and only for that index.<p>No other indexes are impacted, and an index can only be impacted when the updates on the table don't update indexed columns.<p>Nevertheless, if you frequently run CIC, you could be having this issue -- right now you can detect the issue with amcheck, and fix it with a non-concurrent REINDEX of the index (yes, this locks the table).<p>Alternatively (not listed in the blog post, but possible if you can't afford table locks), you should be able to safely CIC (without corruption) by doing manual snapshot control while concurrently reindexing the index (takes 3 database sessions):<p>In session 1 start a REPEATABLE READ read-only transaction.
In session 2, start the concurrent (re)index.
In session 3, monitor pg_stat_progress_create_index for session 2 to get to a 'waiting for ...' phase.<p>When you detect the (re)index session arrives in a waiting phase, start a REPEATABLE READ transaction in this session, and then halt (commit or rollback doesn't matter) the transaction in session 1. Now, we switch roles of sessions 1 and 3, and repeat this lock-step while the session that is (re)indexing hasn't completed.