Re: [BUG] Error in BRIN summarization
Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-08-10T17:30:44Z
Lists: pgsql-hackers
Attachments
- brin_pagelock_fix_REL_12_v1.patch (text/x-patch) patch v1
- brin_summarize_fix_REL_12_v2.patch (text/x-patch) patch v2
On 30.07.2020 16:40, Anastasia Lubennikova wrote: > While testing this fix, Alexander Lakhin spotted another problem. > > After a few runs, it will fail with "ERROR: corrupted BRIN index: > inconsistent range map" > > The problem is caused by a race in page locking in > brinGetTupleForHeapBlock [1]: > > (1) bitmapsan locks revmap->rm_currBuf and finds the address of the > tuple on a regular page "page", then unlocks revmap->rm_currBuf > (2) in another transaction desummarize locks both revmap->rm_currBuf > and "page", cleans up the tuple and unlocks both buffers > (1) bitmapscan locks buffer, containing "page", attempts to access the > tuple and fails to find it > > > At first, I tried to fix it by holding the lock on revmap->rm_currBuf > until we locked the regular page, but it causes a deadlock with > brinsummarize(), It can be easily reproduced with the same test as above. > Is there any rule about the order of locking revmap and regular pages > in brin? I haven't found anything in README. > > As an alternative, we can leave locks as is and add a recheck, before > throwing an error. > Here are the updated patches for both problems. 1) brin_summarize_fix_REL_12_v2 fixes "failed to find parent tuple for heap-only tuple at (50661,130) in table "tbl'" This patch checks that we only access initialized entries of root_offsets[] array. If necessary, collect the array again. One recheck is enough here, since concurrent pruning is not possible. 2) brin_pagelock_fix_REL_12_v1.patch fixes "ERROR: corrupted BRIN index: inconsistent range map" This patch adds a recheck as suggested in previous message. I am not sure if one recheck is enough to eliminate the race completely, but the problem cannot be reproduced anymore. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Commits
-
Disable autovacuum for BRIN test table
- b83f1bcca0bb 13.0 landed
- 6e70443edacf 14.0 landed
- 4f47c8e7d438 12.5 landed
- 060e5bd70e4d 11.10 landed
- d4d21490376e 9.6.20 landed
- aa4da2674ca2 9.5.24 landed
- 3a45ac076aab 10.15 landed
-
Handle new HOT chains in index-build table scans
- e5902117dd83 9.6.20 landed
- a811ea5bde2f 14.0 landed
- 704de3739c5b 11.10 landed
- 40bceae7b4de 9.5.24 landed
- 385cbe8e4197 10.15 landed
- 2f29fd4cb252 13.0 landed
- 1122a903e967 12.5 landed
-
BRIN: Handle concurrent desummarization properly
- ce3a8fde8e62 9.5.24 landed
- 8782ea2f36a2 13.0 landed
- 7af39993a47c 11.10 landed
- 7a3c261fbbb4 9.6.20 landed
- 721ef4d28aae 10.15 landed
- 1f42d35a1d61 14.0 landed
- 0426c75e7d1d 12.5 landed