Rafael Martinez <r.m.guerrero@usit.uio.no> writes:
> I send you the information you ask for.
This is really interesting. Looking at tuple 44 in the pg_filedump
output:
> Item 44 -- Length: 88 Offset: 4016 (0x0fb0) Flags: USED
> XID: min (34365810) CMIN|XMAX: 0 CMAX|XVAC: 0
> Block Id: 174 linp Index: 44 Attributes: 6 Size: 28
> infomask: 0x0913
> (HASNULL|HASVARWIDTH|HASOID|XMIN_COMMITTED|XMAX_INVALID)
> t_bits: [0]: 0x2f
> 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
whereas what we saw in the gdb output was:
> (gdb) x/10 3054556648
> 0xb610d5e8: 0x2f00000c 0x00000002 0x30170000 0x020c6172
> 0xb610d5f8: 0x00000000 0x00000000 0x00ae0000 0x0006002b
> 0xb610d608: 0x2f1c0913 0x0404b70b
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. 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?
regards, tom lane