Re: [HACKERS] dec alpha/64bit stuff - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] dec alpha/64bit stuff
Date
Msg-id 3500E0A1.B04E3CD9@alumni.caltech.edu
Whole thread Raw
In response to dec alpha/64bit stuff  (Brett McCormick <brett@work.chicken.org>)
Responses Re: [HACKERS] dec alpha/64bit stuff
Re: [HACKERS] dec alpha/64bit stuff
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: subselects
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] dec alpha/64bit stuff