FAQ
I got this bug in 6.0 3 weeks ago, but was decided that it may be
caused by other reasons: by freeing memory after a command done in big
transaction. I turned freeing OFF, but got this again, today.

It caused by deletion all minimum keys from an index page and
insertion (up to page splitting) higher duplicate keys. After this parent
page is inconsistent: item_with_old_minimum_key (K1) points to child
page with higher_minimum_key (K2, K2 > K1), and the next item in parent
with key K2 points to right sibling.
Now, if we scan for key = K2 then parent item with key K1 will
be ignored and we'll lost some valid items on the left-sibling.

Reproduction in 6.1 (it uses BTREE_VERSION_1: under 1.x, 6.0
other # of records and other values in WHERE should be used):

create table bug (x int, y int);
create index bug_in_btree on bug (x);
copy bug from '/home/postgres/My/Btree/BUG/I_1';
- -- ^^^
- -- 450 records with x = 1, y in [1,450]
copy bug from '/home/postgres/My/Btree/BUG/I_3';
- -- ^^^
- -- 300 records with x = 3
delete from bug where ( x = 1 and y >= 1 and y <= 203 );
delete from bug where ( x = 1 and y = 409 );
- -- By here, rows from heap, which are corresponding to
- -- all items with key == 1 on second index page, are gone.
vacuum verbose bug;
- -- And index items are gone too.
copy bug from '/home/postgres/My/Btree/BUG/I_2';
- -- ^^^
- -- 450 records with x = 2

And now:
vac=> select count(*) from bug where x = 2;
count
- -----
245
(1 row)

vac=> drop index bug_in_btree;
DROP
vac=> select count(*) from bug where x = 2;
count
- -----
450
(1 row)

I hope to fix it 26-27 May.

Bye,
Vadim

------------------------------

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 23, '97 at 8:52a
activeMay 23, '97 at 8:52a
posts1
users1
websitepostgresql.org...
irc#postgresql

1 user in discussion

Vadim B. Mikheev: 1 post

People

Translate

site design / logo © 2022 Grokbase