From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Subject: | Re: Corrupted btree index on HEAD because of covering indexes |
Date: | 2018-04-19 05:29:39 |
Message-ID: | 5b51b85a-b421-24b2-fb42-9a9b67e43b84@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Catalin Iacob | 2018-04-19 05:30:08 | Is a modern build system acceptable for older platforms |
Previous Message | Michael Paquier | 2018-04-19 05:24:36 | Corrupted btree index on HEAD because of covering indexes |