Marc Munro <marc@bloodnok.com> writes:
> Tom,
> we have a newer and much smaller (35M) file showing the same thing:
Thanks. Looking into this, what I find is that *both* indexes have
duplicated entries for the same heap tuple:
idx1:
Item 190 -- Length: 24 Offset: 3616 (0x0e20) Flags: USED Block Id: 27806 linp Index: 2 Size: 24 Has Nulls: 0 Has
Varwidths:0
0e20: 00009e6c 02001800 01000000 0057d123 ...l.........W.# 0e30: 1a781200 00000000 .x......
Item 191 -- Length: 24 Offset: 3592 (0x0e08) Flags: USED Block Id: 27806 linp Index: 2 Size: 24 Has Nulls: 0 Has
Varwidths:0
0e08: 00009e6c 02001800 01000000 0057d123 ...l.........W.# 0e18: 2e781200 00000000 .x......
idx2:
Item 127 -- Length: 16 Offset: 6144 (0x1800) Flags: USED Block Id: 27806 linp Index: 2 Size: 16 Has Nulls: 0 Has
Varwidths:0
1800: 00009e6c 02001000 0057d123 00000000 ...l.....W.#....
Item 128 -- Length: 16 Offset: 6128 (0x17f0) Flags: USED Block Id: 27806 linp Index: 2 Size: 16 Has Nulls: 0 Has
Varwidths:0
17f0: 00009e6c 02001000 0057d123 00000000 ...l.....W.#....
However, the two entries in idx1 contain different data!!
What I speculate right at the moment is that we are not looking at index
corruption at all, but at heap corruption: somehow, the first insertion
into ctid (27806,2) got lost and the same ctid got re-used for the next
inserted row. We fixed one bug like this before ...
regards, tom lane
