Fix duplicate arbiter detection during REINDEX CONCURRENTLY on partitions
Álvaro Herrera <alvherre@kurilemu.de>
Fix duplicate arbiter detection during REINDEX CONCURRENTLY on partitions Commit 90eae926a fixed ON CONFLICT handling during REINDEX CONCURRENTLY on partitioned tables by treating unparented indexes as potential arbiters. However, there's a remaining race condition: when pg_inherits records are swapped between consecutive calls to get_partition_ancestors(), two different child indexes can appear to have the same parent, causing duplicate entries in the arbiter list and triggering "invalid arbiter index list" errors. Note that this is not a new problem introduced by 90eae926a. The same error could occur before that commit in a slightly different scenario: an index is selected during planning, then index_concurrently_swap() commits, and a subsequent call to get_partition_ancestors() uses a new catalog snapshot that sees zero ancestors for that index. Fix by tracking which parent indexes have already been processed. If a subsequent call to get_partition_ancestors() returns a parent we've already seen, treat that index as unparented instead, allowing it to be matched via IsIndexCompatibleAsArbiter() like other concurrent reindex scenarios. Author: Mihail Nikalayeu <mihailnikalayeu@gmail.com> Reported-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Discussion: https://postgr.es/m/e5a8c1df-04e5-4343-85ef-5df2a7e3d90c@gmail.com
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/executor/execPartition.c | modified | +27 −8 |
| src/test/modules/test_misc/t/010_index_concurrently_upsert.pl | modified | +45 −0 |
Discussion
- Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY 99 messages · 2024-06-11 → 2026-01-28