Re: new heapcheck contrib module

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: new heapcheck contrib module
Дата
Msg-id 113947.1603417275@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: new heapcheck contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: new heapcheck contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: new heapcheck contrib module  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список pgsql-hackers
I wrote:
> 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.

Just to make sure, I tried this test program:

#include <stdio.h>
#include <string.h>

typedef struct ItemIdData
{
    unsigned    lp_off:15,      /* offset to tuple (from start of page) */
                lp_flags:2,     /* state of line pointer, see below */
                lp_len:15;      /* byte length of tuple */
} ItemIdData;

int main()
{
    ItemIdData lp;

    memset(&lp, 0x77, sizeof(lp));
    printf("off = %x, flags = %x, len = %x\n",
           lp.lp_off, lp.lp_flags, lp.lp_len);
    return 0;
}

I get

off = 7777, flags = 2, len = 3bbb

on a little-endian machine, and

off = 3bbb, flags = 2, len = 7777

on big-endian.  It'd be less symmetric if the bytes weren't
all the same ...

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andy Fan
Дата:
Сообщение: Would it be helpful for share the patch merge result from cfbot
Следующее
От: Tom Lane
Дата:
Сообщение: Re: new heapcheck contrib module