Обсуждение: Postgres 6.4.1 on DEC-ALPHA
Hi,
I'm having real problem to get postgres 6.4.1 to run on Alpha. It
compiled with only one minor problem, but when I try to do anything
(createdb, or psql template1) i get the following
> createdb
Connection to database 'template1' failed.
FATAL 1: palloc failure: memory exhausted
createdb: database creation failed on postgres.
Running the postmaster -i -d 5 I get
-----------------------------------------
/data/pgsql/bin/postmaster: BackendStartup: pid 7916 user postgres db
template1
socket 5
/data/pgsql/bin/postmaster child[7916]: starting with
(/data/pgsql/bin/postgres,
-p, -d5, -P5, -v131072, template1, )
FindExec: found "/data/pgsql/bin/postgres" using argv[0]
debug info:
User = postgres
RemoteHost = localhost
RemotePort = 0
DatabaseName = template1
Verbose = 5
Noversion = f
timings = f
dates = Normal
bufsize = 64
sortmem = 512
query echo = f
InitPostgres
FATAL 1: palloc failure: memory exhausted
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
/data/pgsql/bin/postmaster: reaping dead processes...
/data/pgsql/bin/postmaster: CleanupProc: pid 7916 exited with status 0
Does anybody have any idea where this palloc failure comes from? I've
had postgres 6.3.2 running without
any problems. And the machine has got over 600MB of memory, so that
isn't the problem.
Cheers,
Adriaan
On Tue, 22 Dec 1998, Adriaan Joubert wrote: > Hi, > > I'm having real problem to get postgres 6.4.1 to run on Alpha. It > compiled with only one minor problem, but when I try to do anything > (createdb, or psql template1) i get the following > I have been unable to get postgres 6.4 to compile on our DEC Alphas running Digital Unix 4.0d. What version of the DEC OS are you running, and what did you have to do to make it compile? Thanks for your help, Carl Carl G. Riches Software Engineer Department of Mathematics Box 354350 voice: 206-543-5082 or 206-616-3636 University of Washington fax: 206-543-0397 Seattle, WA 98195-4350 internet: riches@ms.washington.edu
I managed to compile postgres 6.4.1 without too much hassle, with the following ./configure --with-CC=cc --without-CXX There was only a single problem in /data/build/pgsql/src/backend/port/snprintf.c where around line 120 it should read #ifndef HAVE_LONG_INT_64 static void fmtnum __P((long_long value, int base, int dosign, int ljust, int le n, int zpad)); #else static void fmtnum __P((long value, int base, int dosign, int ljust, int len, in t zpad)); #endif Then everything is fine. Don't even try with gcc -- I've also tried with the gcc from egcs 1.0.3 and there are a lot of errors. Problem is that even when postgres has compiled, it isn't working. I've spent most of two days on this now, but am back on 6.3.2 now (sigh). Adriaan
> I managed to compile postgres 6.4.1 without too much hassle, with the
> following
>
> ./configure --with-CC=cc --without-CXX
>
> There was only a single problem in
>
> /data/build/pgsql/src/backend/port/snprintf.c
>
> where around line 120 it should read
>
>
> #ifndef HAVE_LONG_INT_64
> static void fmtnum __P((long_long value, int base, int dosign, int ljust,
> int le
> n, int zpad));
> #else
> static void fmtnum __P((long value, int base, int dosign, int ljust, int
> len, in
> t zpad));
> #endif
Huh? What platform are you using?
It currently reads:
#ifndef HAVE_LONG_LONG_INT_64
static void fmtnum __P((long value, int base, int dosign, int ljust, int len, i$
#else
static void fmtnum __P((long_long value, int base, int dosign, int ljust, int l$
#endif
This was a last minute change suggested by someone, and it looked
correct. We are saying if they don't have long long, use long. It that
wrong?
>
>
> Then everything is fine. Don't even try with gcc -- I've also tried with
> the gcc from egcs 1.0.3
> and there are a lot of errors.
>
> Problem is that even when postgres has compiled, it isn't working. I've
> spent most of two days
> on this now, but am back on 6.3.2 now (sigh).
That is bad. Please send us some more info.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Hi all,
> -----Original Message-----
> From: owner-pgsql-general@postgreSQL.org
> [mailto:owner-pgsql-general@postgreSQL.org]On Behalf Of Bruce Momjian
> Sent: Thursday, December 24, 1998 6:14 AM
> To: Adriaan Joubert
> Cc: riches@ms.washington.edu; pgsql-general@postgreSQL.org
> Subject: Re: [GENERAL] Postgres 6.4.1 on DEC-ALPHA
>
>
> > I managed to compile postgres 6.4.1 without too much hassle, with the
> > following
> >
> > ./configure --with-CC=cc --without-CXX
> >
> > There was only a single problem in
> >
> > /data/build/pgsql/src/backend/port/snprintf.c
> >
> > where around line 120 it should read
> >
> >
> > #ifndef HAVE_LONG_INT_64
> > static void fmtnum __P((long_long value, int base, int dosign,
> int ljust,
> > int le
> > n, int zpad));
> > #else
> > static void fmtnum __P((long value, int base, int dosign, int ljust, int
> > len, in
> > t zpad));
> > #endif
>
On my platform(Solaris 2.51 x86),I also have the same problem.
And moreover there is another problem.
On my platform,type long long exists and the following step
unsigned long_long uvalue;
causes compilation error(gcc version is 2.7.2.3). long_long is
typedef'd and unsigned (typedef) is out of specification ?
Hiroshi Inoue
Inoue@tpf.co.jp
*** src/backend/port/snprintf.c.orig Fri Dec 18 17:00:23 1998
--- src/backend/port/snprintf.c Wed Dec 23 16:27:05 1998
***************
*** 48,53 ****
--- 48,54 ----
/* IRIX doesn't do 'long long' in va_arg(), so use a typedef */
#ifdef HAVE_LONG_LONG_INT_64
typedef long long long_long;
+ typedef unsigned long long unsigned_long_long;
#endif
/*
***************
*** 114,120 ****
static void fmtstr __P((char *value, int ljust, int len, int zpad, int
maxwidth));
! #ifndef HAVE_LONG_INT_64
static void fmtnum __P((long value, int base, int dosign, int ljust, int
len, int zpad));
#else
static void fmtnum __P((long_long value, int base, int dosign, int ljust,
int len, int zpad));
--- 115,121 ----
static void fmtstr __P((char *value, int ljust, int len, int zpad, int
maxwidth));
! #ifndef HAVE_LONG_LONG_INT_64
static void fmtnum __P((long value, int base, int dosign, int ljust, int
len, int zpad));
#else
static void fmtnum __P((long_long value, int base, int dosign, int ljust,
int len, int zpad));
***************
*** 350,356 ****
{
int signvalue = 0;
#ifdef HAVE_LONG_LONG_INT_64
! unsigned long_long uvalue;
#else
unsigned long uvalue;
#endif
--- 351,357 ----
{
int signvalue = 0;
#ifdef HAVE_LONG_LONG_INT_64
! unsigned_long_long uvalue;
#else
unsigned long uvalue;
#endif
[Charset iso-8859-1 unsupported, filtering to ASCII...] > Hi all, > > > -----Original Message----- > > From: owner-pgsql-general@postgreSQL.org > > [mailto:owner-pgsql-general@postgreSQL.org]On Behalf Of Bruce Momjian > > Sent: Thursday, December 24, 1998 6:14 AM > > To: Adriaan Joubert > > Cc: riches@ms.washington.edu; pgsql-general@postgreSQL.org > > Subject: Re: [GENERAL] Postgres 6.4.1 on DEC-ALPHA > > > > > > > I managed to compile postgres 6.4.1 without too much hassle, with the > > > following > > > > > > ./configure --with-CC=cc --without-CXX > > > > > > There was only a single problem in > > > > > > /data/build/pgsql/src/backend/port/snprintf.c > > > > > > where around line 120 it should read > > > > > > > > > #ifndef HAVE_LONG_INT_64 > > > static void fmtnum __P((long_long value, int base, int dosign, > > int ljust, > > > int le > > > n, int zpad)); > > > #else > > > static void fmtnum __P((long value, int base, int dosign, int ljust, int > > > len, in > > > t zpad)); > > > #endif > > > > On my platform(Solaris 2.51 x86),I also have the same problem. > And moreover there is another problem. > > On my platform,type long long exists and the following step > > unsigned long_long uvalue; > > causes compilation error(gcc version is 2.7.2.3). long_long is > typedef'd and unsigned (typedef) is out of specification ? Yes, you have found two problems. HAVE_LONG should have been HAVE_LONG_LONG, and you can't unsigned a typedef. I have applied fixes for both of these. This long long stuff was clearly broken, but now that we have configure properly recognizing it, the snprint stuff is showing our problems. Looks like we will need a patch for these problems. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026