Fix corruption of toast indexes with REINDEX CONCURRENTLY

Enterprise / PostgreSQL - Michael Paquier [] - 8 December 2021 02:01 UTC

REINDEX CONCURRENTLY run on a toast index or a toast relation could corrupt the target indexes rebuilt, as a backend running in parallel that manipulates toast values would directly release the lock on the toast relation when its local operation is done, rather than releasing the lock once the transaction that manipulated the toast values committed.

The fix done here is simple: we now hold a ROW EXCLUSIVE lock on the toast relation when saving or deleting a toast value until the transaction working on them is committed, so as a concurrent reindex happening in parallel would be able to wait for any activity and see any new rows inserted (or deleted).

An isolation test is added to check after the case fixed here, which is a bit fancy by design as it relies on allow_system_table_mods to rename the toast table and its index to fixed names. This way, it is possible to reindex them directly without any dependency on the OID of the underlying relation. Note that this could not use a DO block either, as REINDEX CONCURRENTLY cannot be run in a transaction block. The test is backpatched down to 13, where it is possible, thanks to c4a7a39, to use allow_system_table_mods in a test suite.

f99870dd86 Fix corruption of toast indexes with REINDEX CONCURRENTLY
src/backend/access/common/toast_internals.c | 16 +-
.../expected/reindex-concurrently-toast.out | 775 +++++++++++++++++++++
src/test/isolation/isolation_schedule | 1 +
.../specs/reindex-concurrently-toast.spec | 119 ++++
4 files changed, 905 insertions(+), 6 deletions(-)


  • Share