Re: new heapcheck contrib module
От | Tom Lane |
---|---|
Тема | Re: new heapcheck contrib module |
Дата | |
Msg-id | 95051.1603406715@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: new heapcheck contrib module (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: new heapcheck contrib module
|
Список | pgsql-hackers |
Mark Dilger <mark.dilger@enterprisedb.com> writes: >> On Oct 22, 2020, at 2:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Oh, wait a second. ItemIdData has the flag bits in the middle: >> meaning that for that particular bit pattern, one endianness >> is going to see the flags as 01 (LP_NORMAL) and the other as 10 >> (LP_REDIRECT). > Well, the issue is that on big-endian machines it is not reporting any > corruption at all. Are you sure the difference will be LP_NORMAL vs > LP_REDIRECT? [ thinks a bit harder... ] Probably not. The byte/bit string looks the same either way, given that it's four repetitions of the same byte value. But which field is which will differ: we have either oooooooooooooooFFlllllllllllllll 01110111011101110111011101110111 or lllllllllllllllFFooooooooooooooo 01110111011101110111011101110111 So now I think this is a REDIRECT on either architecture, but the offset and length fields have different values, causing the redirect pointer to point to different places. Maybe it happens to point at a DEAD tuple in the big-endian case. regards, tom lane
В списке pgsql-hackers по дате отправления: