Important PostgreSQL 14 update to avoid silent corruption of indexes
1–10 of 101 posts
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#2Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#3Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#4Discussion: https://www.postgresql.org/message-id/17485-396609c6925b982d...
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#5This 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.
No other indexes are impacted, and an index can only be impacted when the updates on the table don't update indexed columns.
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).
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):
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.
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.
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#6Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#7It is noted in the post, I'll repeat it to be clear: 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. No other indexes are impacted, and an index can only be impacted when the updates on the table don't update indexed columns. Nevertheless, if you frequently run CIC, you could be having this issue -- right…
For PG14 the maintaining of that horizon was disabled for backends that run CIC/RIC, resulting in this bug. If you manually keep that horizon from moving using other backends on the same database, the old versions that CIC/RIC expects will not be removed, and thus no corruption will occur.
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#8Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#9Also 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.
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#10Looking at the file with changes https://github.com/postgres/postgres/blob/master/src/backend... , 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.