Thread: postgres initdb on ALPHA/Digital Unix
On Wed, 11 Feb 1998, Kenji T. Hollis wrote:
>> Brian:
>>
>> > > I wrote a message about 4 months ago asking about an Alpha Linux version
>> > > of PostGreSQL. Last I heard, they were working on it and it would be
>> > > released in early January with a 64-bit clean version of the server.
>> > >
>> > > This is my third request.
>> >
>> > So, fix it your own self and stop whining. Can't fix it? Too bad, I
>> > guess you'll just have to wait until they get around to it.
>>
>> Is this how you guys normally handle inquiries? Idiot replies like this?
>> Oh by the way, I tried fixing it. Next question?
>
> No, this isn't...generally we tend to try and point you in the
>right direction towards determining the problem...
>
> ...first question is, how many ppl out there are running under a
>Linux/Alpha platform, or at least are trying? I don't have one myself, so
>can only be of limited help...
>
I have been trying to build Postgres 6.3 on an Alpha, running Digital
Standard Unix, and have been finding a similar problem to Ken Hollis,
once I succeeded in getting the thing to compile cleanly
[...]
>
>ERROR: BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
>ERROR: BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
>
Get a similar problem to the above
This problem has also occurred
1. using native cc instead of gcc
2. encouraging native cc to restrict image to 32 bits (-taso flag) at
ld time.
Forcing pointers to 32 bits with native cc by use of the -xtaso_short
CC and LD flags dies with errors related to varargs datatypes, so I
haven't managed to investigate this further.
I originally also encountered these errors with postgres 6.2.1, but
given the iminent release of 6.3 and significant other distractions, I
decided to wait for this before revisiting the issue.
I have already posted this problem to the pgsql-ports mailing list,
but it is less that totally evident from our remote location what is
the best strategy, so I await developments here on 64 bit issues with
interest.
regards
Peter A. Stockwell
peter@sanger.otago.ac.nz
On Fri, 13 Feb 1998, Peter Stockwell wrote:
> On Wed, 11 Feb 1998, Kenji T. Hollis wrote:
>
> I have already posted this problem to the pgsql-ports mailing list,
> but it is less that totally evident from our remote location what is
> the best strategy, so I await developments here on 64 bit issues with
> interest.
all I can say to both you and Kenji...please stay vocal in here.
As Bruce has already shown, about the best we can offer is to try to help
point you in the right directions towards fixing this, but the fix has to
come from you guys. Use this list (or, preferrably, pgsql-ports) to
discuss this issues amongst yourself...we'll throw in ideas as we can
think of them, but you are the ones that have to act on the ideas...
Peter, how much experience do you have with gdb? I don't know if
this would help any (Bruce, comments?), but if you are reasonably familiar
with gdb, make a debug (-g) postmaster/postgres binary, and when it core
dumps (I believe Kenji said that it did core dump), do an analysis of the
core using gdb. If nothing more then doing a 'where' inside of gdb to
show us the sequence of functions leading to the dump, and then hopefully
one of us will be able to suggest where to go next, as well as what
variables should be printed out at those points to give an idea of what
may be wrong...
Hell, if it helps any, I'll do the manual aspect of this if
someone wants to give me access to their machine, and try to work with
Bruce on this *shrug*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > I have already posted this problem to the pgsql-ports mailing list, > > but it is less that totally evident from our remote location what is > > the best strategy, so I await developments here on 64 bit issues with > > interest. > Hell, if it helps any, I'll do the manual aspect of this if > someone wants to give me access to their machine, and try to work with > Bruce on this *shrug* Does this problem only appear on ALPHA machines or also on other 64 bit architectures? I might be able to find a 64 bit machine on my university on which I can do a compile/initdb/gdb run if that helps.... sparc stations 20 are 32 bits aren't they? Then that machine does not qualify. We are getting an ultra-sparc soon though, and there might be some alpha's around. 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 Fri, 13 Feb 1998, Maarten Boekhold wrote:
> > > I have already posted this problem to the pgsql-ports mailing list,
> > > but it is less that totally evident from our remote location what is
> > > the best strategy, so I await developments here on 64 bit issues with
> > > interest.
>
> > Hell, if it helps any, I'll do the manual aspect of this if
> > someone wants to give me access to their machine, and try to work with
> > Bruce on this *shrug*
>
> Does this problem only appear on ALPHA machines or also on other 64 bit
> architectures? I might be able to find a 64 bit machine on my university
> on which I can do a compile/initdb/gdb run if that helps....
We just also had a report from one Dec ALPHA user that he's been
using PostgreSQL since the v6.0 days with no problems...most curious...
> sparc stations 20 are 32 bits aren't they? Then that machine does not
> qualify. We are getting an ultra-sparc soon though, and there might be
> some alpha's around.
I hate to sound stupid, but an Ultra1...that's a 64bit machine?
If so, then I too have been running it on a 64bit machine, with absolutely
no problems, for almost 6 months now...
> > sparc stations 20 are 32 bits aren't they? Then that machine does not > > qualify. We are getting an ultra-sparc soon though, and there might be > > some alpha's around. > > I hate to sound stupid, but an Ultra1...that's a 64bit machine? > If so, then I too have been running it on a 64bit machine, with absolutely > no problems, for almost 6 months now... Yup, see http://www.sun.com/sparc/Net.Engine/ for more info..... 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 | -----------------------------------------------------------------------------
> > I hate to sound stupid, but an Ultra1...that's a 64bit machine? > > If so, then I too have been running it on a 64bit machine, with absolutely > > no problems, for almost 6 months now... > > Yup, see http://www.sun.com/sparc/Net.Engine/ for more info..... I'm not familiar with the 64-bit Sparc machines, but is it possible that the OS and compilers default to a 32-bit mode? I believe that they did at one time... - Tom
On Fri, 13 Feb 1998, Thomas G. Lockhart wrote: > > > I hate to sound stupid, but an Ultra1...that's a 64bit machine? > > > If so, then I too have been running it on a 64bit machine, with absolutely > > > no problems, for almost 6 months now... > > > > Yup, see http://www.sun.com/sparc/Net.Engine/ for more info..... > > I'm not familiar with the 64-bit Sparc machines, but is it possible that > the OS and compilers default to a 32-bit mode? I believe that they did > at one time... I got a private email stating that it isn't until v2.6 that the OS actually starts to really use the 64bit stuff (I'm summarizing here)...I'm doing my testing on both x86 and sparc v2.6, and so far, no noticeable problems...
>>>>> "scrappy" == The Hermit Hacker <scrappy@hub.org> writes:
> On Fri, 13 Feb 1998, Maarten Boekhold wrote:
>> > > I have already posted this problem to the pgsql-ports
>> mailing list, > > but it is less that totally evident from our
>> remote location what is > > the best strategy, so I await
>> developments here on 64 bit issues with > > interest.
>>
>> > Hell, if it helps any, I'll do the manual aspect of this if >
>> someone wants to give me access to their machine, and try to
>> work with > Bruce on this *shrug*
>>
>> Does this problem only appear on ALPHA machines or also on
>> other 64 bit architectures? I might be able to find a 64 bit
>> machine on my university on which I can do a compile/initdb/gdb
>> run if that helps....
> We just also had a report from one Dec ALPHA user that he's
> been using PostgreSQL since the v6.0 days with no
> problems...most curious...
>> sparc stations 20 are 32 bits aren't they? Then that machine
>> does not qualify. We are getting an ultra-sparc soon though,
>> and there might be some alpha's around.
> I hate to sound stupid, but an Ultra1...that's a 64bit
> machine? If so, then I too have been running it on a 64bit
> machine, with absolutely no problems, for almost 6 months now...
Sparc Ultra are 64 bits, but Solaris is only a 32 bit OS. The only 64
bit machines (with 64 bit OS's) would be some SGI's and Alphas.
Kent S. Gordon
Architect
iNetSpace Co.
voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com