Re: [HACKERS] dec alpha/64bit stuff

Поиск
Список
Период
Сортировка
От Thomas G. Lockhart
Тема Re: [HACKERS] dec alpha/64bit stuff
Дата
Msg-id 3500E0A1.B04E3CD9@alumni.caltech.edu
обсуждение исходный текст
Ответ на dec alpha/64bit stuff  (Brett McCormick <brett@work.chicken.org>)
Ответы Re: [HACKERS] dec alpha/64bit stuff  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] dec alpha/64bit stuff  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
Brett McCormick wrote:

> whew.. after some more debugging, it would appear that the problem
> lies somewhere in the page stuff, which I know less than nothing
> about.
>
> Here's the point where I'm at: heapam.c line 442 a macro call to
> HeapTupleSatisfies graps our data for us (the messed up struct), which
> actually calls the PageGetItem macro for the data.
>
> but, the curious thing is that the relation pointer that gets passed
> to both heapgettup and the macro calls contains the correct struct in
> relation->rd_att->attrs[0], but then a faulty one is being returned by
> PageGetItem.  PageGetItem just appears to return a pointer somewhere
> in the page..  where does this page stuff get written?  I'm not sure
> how much farther I can go..  I'll check out the backend flowchart for
> more info.
>
> I might also do a diff to see which page stuff has changed..  Is it
> possible to back out the atttypmod changes to see if that fixes it?

I predict that if you pump up attypmod to a 32 bit field your problems
will go away. I'll bet that the page is being read off of disk and the
struct is memcpy'd (or something similar) into it, rather than being
copied field-by-field. The struct internal alignments are off for the
Alpha, which will pad structs to get the optimal access alignment.

                                                                  - Tom


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: subselects
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] dec alpha/64bit stuff