[Tom Lane]:
>
> This evidently corresponds to data starting at offset 0ffc on the
> disk page (the last few bytes of the gdb output match the start of
> tuple 43, which is in the next higher part of the page --- note
> that the bytes are being printed in opposite orders by pg_filedump
> and gdb). So somehow, the byte at page offset 0fff got changed
> from 00 to 2f in memory, though not on disk.
indeed interesting. IMHO 0x0fff sounds more like a write to -1
(relative to the next page) than a random memory error.
> If you still have the core dump, would you look at the area
> surrounding address 3054556648 and see if there are any other
> discrepancies between that and what is on disk?
I can't see any further discrepancies:
(gdb) x/20 3054556572
0xb610d59c: 0x020c6172 0x00000000 0x00000000 0x00ae0000
0xb610d5ac: 0x0006002c 0x2f1c0913 0x0404b70c 0x0000000c
0xb610d5bc: 0x00000004 0x69480000 0x0000000c 0x00000003
0xb610d5cc: 0x81960000 0x0000000c 0x00000003 0x02100000
0xb610d5dc: 0x0000000c 0x00000002 0x30120000 0x2f00000c
> 0fb0: 72610c02 00000000 00000000 0000ae00 ra..............
> 0fc0: 2c000600 13091c2f 0cb70404 0c000000 ,....../........
> 0fd0: 04000000 00004869 0c000000 03000000 ......Hi........
> 0fe0: 00009681 0c000000 03000000 00001002 ................
> 0ff0: 0c000000 02000000 00001230 0c000000 ...........0....
> 1000: 02000000 00001730 .......0
thank you for your tremendous assistance!
--
Kjetil T.
