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.
Looking at the file with changes <a href="https://github.com/postgres/postgres/blob/master/src/backend/storage/ipc/procarray.c" rel="nofollow">https://github.com/postgres/postgres/blob/master/src/backend...</a> , I have to say this source code repository is so well documented/commented and structured, I really gives you a huge trust in postgres to be used in your stack.
A more official announcement seems to be at <a href="https://www.postgresql.org/message-id/165473835807.573551.1512237163040609764%40wrigleys.postgresql.org" rel="nofollow">https://www.postgresql.org/message-id/165473835807.573551.15...</a>
I think this is the fix: <a href="https://github.com/postgres/postgres/commit/e28bb885196916b0a3d898ae4f2be0e38108d81b" rel="nofollow">https://github.com/postgres/postgres/commit/e28bb885196916b0...</a><p>Discussion: <a href="https://www.postgresql.org/message-id/17485-396609c6925b982d%40postgresql.org" rel="nofollow">https://www.postgresql.org/message-id/17485-396609c6925b982d...</a>
It’s impressive that this is a single revert. That speaks to how the development of Postgres is done atomically.<p>Also not surprised to see it was the EDB team with the expertise to fix it. Their model is a little outdated but they have a lot of experts working there.
I love Postgres. But when I look at the bug list of every release it makes me scared. The types of bugs they have are indicative of a poor development process.