Re: Corrupted btree index on HEAD because of covering indexes - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: Corrupted btree index on HEAD because of covering indexes
Date
Msg-id 5b51b85a-b421-24b2-fb42-9a9b67e43b84@sigaev.ru
Whole thread Raw
In response to Corrupted btree index on HEAD because of covering indexes  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Corrupted btree index on HEAD because of covering indexes
List pgsql-hackers
Will see...

Michael Paquier wrote:
> Hi all,
> 
> I was just testing the VACUUM truncation logic, and bumped into what
> looks like a corrupted btree index.  Here is a reproducer:
> create table aa (a int primary key, b bool);
> insert into aa values (generate_series(1,1000000), false);
> checkpoint;
> update aa set b = false where a > 500000; -- Dirties a set of shared
> buffers
> delete from aa where a > 750000; -- Delete a set of rows
> vacuum aa;
> delete from aa where a > 10;
> vacuum aa; -- error on btree with right sibling
> 
> And here is the actual failure when the second vacuum:
> ERROR:  XX000: right sibling 4132 of block 2128 is not next child 5396 of block 412 in index "aa_pkey"
> LOCATION:  _bt_mark_page_halfdead, nbtpage.c:1564
> 
> This works on REL_10_STABLE, so I am adding an open item.  I have not
> investigated the exact problem yet, but bisect is showing me covering
> indexes as the culprit (8224de4).
> 
> Thanks,
> --
> Michael
> 

-- 
Teodor Sigaev                      E-mail: teodor@sigaev.ru
                                       WWW: http://www.sigaev.ru/


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Corrupted btree index on HEAD because of covering indexes
Next
From: Catalin Iacob
Date:
Subject: Is a modern build system acceptable for older platforms