dec alpha/64bit stuff

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

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.

Ooooh, good guess. Can't wait to hear if it is correct.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

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.

OK, I have an idea. Contact Marc, scrappy@postgresql.org. Have him
give you a login account to postgresql.org. Use cvs to pull snapshots
by date. Compile and run initdb on several dates, and by process of
elimination, find out the day that alpha broke.

We can then analyze the patches for that day and find the problem. I
assume 6.2.1 worked for you, and that was October 17th. Go from there
to the 6.3 release and find the date of failure.

With initdb problems, there is really no good way to debug problems like
this.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

OK, I have an idea. Contact Marc, scrappy@postgresql.org. Have him
give you a login account to postgresql.org. Use cvs to pull snapshots
by date. Compile and run initdb on several dates, and by process of
elimination, find out the day that alpha broke.

We can then analyze the patches for that day and find the problem. I
assume 6.2.1 worked for you, and that was October 17th. Go from there
to the 6.3 release and find the date of failure.

With initdb problems, there is really no good way to debug problems like
this.

Another suggestion: use a binary search to find the date it broke. Will
save you a lot of time :)

Maarten

_____________________________________________________________________________
| TU Delft, The Netherlands, Faculty of Information Technology and Systems |
| Department of Electrical Engineering |
| Computer Architecture and Digital Technique section |
| M.Boekhold@et.tudelft.nl |
-----------------------------------------------------------------------------

OK, I have an idea. Contact Marc, scrappy@postgresql.org. Have him
give you a login account to postgresql.org. Use cvs to pull snapshots
by date. Compile and run initdb on several dates, and by process of

^^^^^^^^^^^

elimination, find out the day that alpha broke.

^^^^^^^^^^^

Another suggestion: use a binary search to find the date it broke. Will
save you a lot of time :)

Was it not clear that is was I was suggesting? Try mid-January first,
then mid December or mid-February, depending on whether mid-January works.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

A binary search?

On Sun, 8 March 1998, at 11:40:52, Maarten Boekhold wrote:

On Sat, 7 March 1998, at 18:10:36, Bruce Momjian wrote:

OK, I have an idea. Contact Marc, scrappy@postgresql.org. Have him
give you a login account to postgresql.org. Use cvs to pull snapshots
by date. Compile and run initdb on several dates, and by process of
elimination, find out the day that alpha broke.

That's what I've been thinking of, but I haven't had a chance to get
the cvs archive yet.

We can then analyze the patches for that day and find the problem. I
assume 6.2.1 worked for you, and that was October 17th. Go from there
to the 6.3 release and find the date of failure.

With initdb problems, there is really no good way to debug problems like
this.

I found a decent way. I just put a printf(getpid()), sleep 10 in
BootstrapMain. Then I run initdb in one window and gdb in another,
attaching gdb to that postgres -boot process. Worked fairly well
until I got stumped by the page stuff.

On Sat, 7 March 1998, at 18:10:36, Bruce Momjian wrote:

OK, I have an idea. Contact Marc, scrappy@postgresql.org. Have him
give you a login account to postgresql.org. Use cvs to pull snapshots
by date. Compile and run initdb on several dates, and by process of
elimination, find out the day that alpha broke.

That's what I've been thinking of, but I haven't had a chance to get
the cvs archive yet.

As I said in another post, by binary search, he meant try Jan 15, and
then Dec 15 or Feb 15 depending on whether Jan 15 worked. Same thing I
expect you were going to do when you could get to the cvs archive.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Doh, silly me. I understood bruce & you.. I thought you meant
executable binary search or something :)

foot in mouth,

On Sun, 8 March 1998, at 15:01:20, Brett McCormick wrote: