Horton

Thread

  1. dec alpha/64bit stuff

    Brett McCormick <brett@work.chicken.org> — 1998-03-07T00:05:59Z

    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?

  2. Re: [HACKERS] dec alpha/64bit stuff

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-07T05:52:33Z

    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

  3. Re: [HACKERS] dec alpha/64bit stuff

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-07T06:06:12Z

    > 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)

  4. Re: [HACKERS] dec alpha/64bit stuff

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-07T23:10:36Z

    > 
> 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)

  5. Re: [HACKERS] dec alpha/64bit stuff

    Maarten Boekhold <maartenb@dutepp0.et.tudelft.nl> — 1998-03-08T10:40:52Z

    > 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                         |
-----------------------------------------------------------------------------

  6. Re: [HACKERS] dec alpha/64bit stuff

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-08T18:05:10Z

    > 
> > 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)

  7. Re: [HACKERS] dec alpha/64bit stuff

    Brett McCormick <brett@work.chicken.org> — 1998-03-08T23:01:20Z

    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                         |
> -----------------------------------------------------------------------------

  8. Re: [HACKERS] dec alpha/64bit stuff

    Brett McCormick <brett@work.chicken.org> — 1998-03-08T23:03:44Z

    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.

  9. Re: [HACKERS] dec alpha/64bit stuff

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-08T23:15:38Z

    > 
> 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)

  10. Re: [HACKERS] dec alpha/64bit stuff

    Brett McCormick <brett@work.chicken.org> — 1998-03-08T23:20:44Z

    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                         |
> > -----------------------------------------------------------------------------