Обсуждение: dec alpha/64bit stuff
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?
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: > 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 | > -----------------------------------------------------------------------------
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.
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: > A binary search? > > On Sun, 8 March 1998, at 11:40:52, Maarten Boekhold wrote: > > > 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 | > > -----------------------------------------------------------------------------
> > 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)