Hello,

I'm a beginner here at the list, my name is Daniel Pellegrini, graduation
student from Brazil with no experience about pgsql. First of all I'd like to
say that I have tried other lists before, but I didn't get the answer, or
the complete answer.

I'm doing a research about DBMSs that run on new PC 64-bit processors, like
Intel Itanium and AMD Opteron. I'd like that you would help me in some
questions. First, does pgsql support this architecture? According to
Administrator's
Guide(http://www.postgresql.org/docs/7.3/static/supported-platforms.html),
there are versions, for example, for SPARC and Alpha, but it doesn't mention
those I'm looking for. In case that the support exists,I'd like to know the
difference between the 32-bit  and the 64-bit versions, if there is some
differences in semantics or something like that or it's just the
implementation and the application features are "transparent" for the user.

Thanks a lot and excuse me about my poor English, please.

Daniel Pellegrini

---
now, in Portuguese:
Olï¿½,

Sou novo aqui na lista, meu nome ï¿½ Daniel Pellegrini, sou estudante de
graduaï¿½ï¿½o no Brasil sem experiï¿½ncia no pgsql. Antes de tudo, gostaria de
dizer que jï¿½ tentei em outras listas mas nï¿½o consegui a resposta, ou a
resposta completa.

Estou fazendo uma pesquisa que trata sobre SGBDs que rodam nos novos
processadores PC de 64 bits, como Intel Itanium e AMD Opteron. Gostaria que
vocï¿½s me ajudassem em algumas questï¿½es. Primeiro, o pgsql dï¿½ suporte a essa
arquitetura? De acordo com o Guia do Administrador
(http://www.postgresql.org/docs/7.3/static/supported-platforms.html),
existem versï¿½es, por exemplo, para SPARC e Alpha, mas nï¿½o fala sobre as
citadas anteriormente. Caso exista o suporte, gostaria de saber a diferenï¿½a
entre as versï¿½es 32 e 64 bits, se hï¿½ alguma diferenï¿½a na semï¿½ntica ou algo
do tipo ou se ï¿½ sï¿½ a implementaï¿½ï¿½o e as caracterï¿½sticas da aplicaï¿½ï¿½o sï¿½o
transparentes para o usuï¿½rio.

Agradeï¿½o desde jï¿½ a atenï¿½ï¿½o.

Daniel Pellegrini

Fri, 5 Sep 2003 11:22:26 -0300
Daniel <danielp@cepedi.org.br>
64-bit pgsql
> I'm doing a research about DBMSs that run on new PC 64-bit processors, like
> Intel Itanium and AMD Opteron. I'd like that you would help me in some
> questions. First, does pgsql support this architecture? According to
> Administrator's
> Guide(http://www.postgresql.org/docs/7.3/static/supported-platforms.html),
> there are versions, for example, for SPARC and Alpha, but it doesn't mention
> those I'm looking for. In case that the support exists,I'd like to know the

Opteron was not publicly accessible 7.3 release was made, thus 7.3 does
not support that platform.  7.4 seems to be functional on that processor
per reports so it will probably be a supported platform for this
release.

Download 7.4 beta 2 and run regression tests on those platforms. Report
back any issues or successes. 7.4 Release candidates will come with a
call for reports on platforms that pass the regression tests which are
used to make up the supported platform list.

> difference between the 32-bit  and the 64-bit versions, if there is some
> differences in semantics or something like that or it's just the
> implementation and the application features are "transparent" for the user.

Not to the SQL interface but some of the structures used are different
-- just as they may change when using different operating systems.
Fri, 05 Sep 2003 10:39:45 -0400
Rod Taylor <rbt@rbt.ca>
Re: 64-bit pgsql
-On [20030905 16:42], Rod Taylor (rbt@rbt.ca) wrote:
>Download 7.4 beta 2 and run regression tests on those platforms. Report
>back any issues or successes. 7.4 Release candidates will come with a
>call for reports on platforms that pass the regression tests which are
>used to make up the supported platform list.

Well, on Itanium2 on FreeBSD 5.1 it compiles.  I just need to get the
semaphores to a higher value in order to actually do an initdb.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
In the world, there is nothing more submissive and weak than water. Yet
for attacking that which is hard and strong, nothing can surpass it... 

Fri, 5 Sep 2003 17:18:58 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: 64-bit pgsql
-On [20030905 17:22], Jeroen Ruigrok/asmodai (asmodai@wxs.nl) wrote:
>Well, on Itanium2 on FreeBSD 5.1 it compiles.  I just need to get the
>semaphores to a higher value in order to actually do an initdb.

Though,

did 7.4 raise the bar on SysV IPC?  On my other two boxes I haven't
tweaked SysV IPC at all (semmni is at 10) and I get initdb.

On this Itanium box when I want to initdb I get:

creating template1 database in /p/scratch/asmodai/postgresql-7.4beta2/src/test/r
egress/./tmp_check/data/base/1... FATAL:  could not create semaphores: No space 
left on device
DETAIL:  Failed syscall was semget(4, 17, 03600).
HINT:  This error does *not* mean that you have run out of disk space.
It occurs when either the system limit for the maximum number of semaphore sets 
(SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exc
eeded.  You need to raise the respective kernel parameter.  Alternatively, reduc
e PostgreSQL's consumption of semaphores by reducing its max_connections paramet
er (currently 100).

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
He who has a why to live for can bear almost any how...

Fri, 5 Sep 2003 17:29:08 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: 64-bit pgsql
On Fri, 2003-09-05 at 11:29, Jeroen Ruigrok/asmodai wrote:
> -On [20030905 17:22], Jeroen Ruigrok/asmodai (asmodai@wxs.nl) wrote:
> >Well, on Itanium2 on FreeBSD 5.1 it compiles.  I just need to get the
> >semaphores to a higher value in order to actually do an initdb.
> 
> Though,
> 
> did 7.4 raise the bar on SysV IPC?  On my other two boxes I haven't
> tweaked SysV IPC at all (semmni is at 10) and I get initdb.

Is this beta 1 or beta 2?  Beta 1 has a bug which may require more
shared resources than what is available.
Fri, 05 Sep 2003 11:37:50 -0400
Rod Taylor <rbt@rbt.ca>
Re: 64-bit pgsql
-On [20030905 17:42], Rod Taylor (rbt@rbt.ca) wrote:
>Is this beta 1 or beta 2?  Beta 1 has a bug which may require more
>shared resources than what is available.

Sorry, beta 2.  Should've made that clear.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Nothing is more honorable than enlightenment, nothing is more beautiful
than virtue...

Fri, 5 Sep 2003 17:43:37 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: 64-bit pgsql
Rod Taylor <rbt@rbt.ca> writes:
>> did 7.4 raise the bar on SysV IPC?  On my other two boxes I haven't
>> tweaked SysV IPC at all (semmni is at 10) and I get initdb.

> Is this beta 1 or beta 2?  Beta 1 has a bug which may require more
> shared resources than what is available.

Actually the bug is in beta2, not beta1.  I'd suggest grabbing the
current nightly snapshot (see /dev on the ftp servers) in preference
to beta2, if you are on a machine with small SysV IPC limits.

We'll probably push out a beta3 as soon as the current IPv6 mess is
sorted.

			regards, tom lane

Fri, 05 Sep 2003 11:45:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 64-bit pgsql 
-On [20030905 17:52], Tom Lane (tgl@sss.pgh.pa.us) wrote:
>Actually the bug is in beta2, not beta1.  I'd suggest grabbing the
>current nightly snapshot (see /dev on the ftp servers) in preference
>to beta2, if you are on a machine with small SysV IPC limits.

Using a snapshot of September the 4th:

creating template1 database in /p/scratch/asmodai/postgresql-snapshot/src/test/r
egress/./tmp_check/data/base/1... FATAL:  could not create semaphores: No space 
left on device
DETAIL:  Failed syscall was semget(4, 17, 03600).
HINT:  This error does *not* mean that you have run out of disk space.
It occurs when either the system limit for the maximum number of semaphore sets 
(SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exc
eeded.  You need to raise the respective kernel parameter.  Alternatively, reduc
e PostgreSQL's consumption of semaphores by reducing its max_connections paramet
er (currently 10).

I mean, I just want to know if you guys still want to support the low
SysV settings.  If not I just need to ask the admins of the system in
question to bump the values a bit.

Otherwise I'll keep pestering. :)

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
In my mind nothing makes sense...

Fri, 5 Sep 2003 18:13:17 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: 64-bit pgsql
Jeroen Ruigrok/asmodai <asmodai@wxs.nl> writes:
> Using a snapshot of September the 4th:

> creating template1 database in /p/scratch/asmodai/postgresql-snapshot/src/test/r
> egress/./tmp_check/data/base/1... FATAL:  could not create semaphores: No space 
> left on device
> DETAIL:  Failed syscall was semget(4, 17, 03600).

> I mean, I just want to know if you guys still want to support the low
> SysV settings.  If not I just need to ask the admins of the system in
> question to bump the values a bit.

If it dies even at max_connections 10, that is a *lower* setting than we
ever supported before (the pre-7.4 default was 32, and you need 20 or
more to run the parallel regression test).  I suspect that you actually
don't have SysV semaphores enabled at all on that machine.  There would
be no point in trying any smaller values.

			regards, tom lane

Fri, 05 Sep 2003 12:28:58 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 64-bit pgsql 
-On [20030905 18:32], Tom Lane (tgl@sss.pgh.pa.us) wrote:
>If it dies even at max_connections 10, that is a *lower* setting than we
>ever supported before (the pre-7.4 default was 32, and you need 20 or
>more to run the parallel regression test).  I suspect that you actually
>don't have SysV semaphores enabled at all on that machine.  There would
>be no point in trying any smaller values.

The SysV semaphores are enabled all right.

As comparison:

Itanium box running 5.1		| Athlon box running 4-STABLE

kern.ipc.msgmax: 16384		| kern.ipc.msgmax: 16384
kern.ipc.msgmni: 40		| kern.ipc.msgmni: 40
kern.ipc.msgmnb: 2048		| kern.ipc.msgmnb: 2048
kern.ipc.msgtql: 40		| kern.ipc.msgtql: 40
kern.ipc.msgssz: 8		| kern.ipc.msgssz: 8
kern.ipc.msgseg: 2048		| kern.ipc.msgseg: 2048
kern.ipc.semmap: 30		| kern.ipc.semmap: 30
kern.ipc.semmni: 10		| kern.ipc.semmni: 10
kern.ipc.semmns: 60		| kern.ipc.semmns: 60
kern.ipc.semmnu: 30		| kern.ipc.semmnu: 30
kern.ipc.semmsl: 60		| kern.ipc.semmsl: 60
kern.ipc.semopm: 100		| kern.ipc.semopm: 100
kern.ipc.semume: 10		| kern.ipc.semume: 10
kern.ipc.semusz: 104		| kern.ipc.semusz: 92
kern.ipc.semvmx: 32767		| kern.ipc.semvmx: 32767
kern.ipc.semaem: 16384		| kern.ipc.semaem: 16384
kern.ipc.shmmax: 67108864	| kern.ipc.shmmax: 33554432
kern.ipc.shmmin: 1		| kern.ipc.shmmin: 1
kern.ipc.shmmni: 192		| kern.ipc.shmmni: 192
kern.ipc.shmseg: 128		| kern.ipc.shmseg: 128
kern.ipc.shmall: 8192		| kern.ipc.shmall: 8192
kern.ipc.shm_use_phys: 0	| kern.ipc.shm_use_phys: 0

The same settings, except for kern.ipc.semusz and kern.ipc.shmmax, which
are higher than on my box running 7.3.4.

So it does seem 7.4 places higher demand than 7.3.4 on the SysV IPC,
since initdb also dies on my Athlon box which normally runs a PostgreSQL
7.3.4 database.

Like I said before, I am not certain if that was intentional, but if it
is a side effect of some change than the docs should emphasize that for
this release the SysV IPC dependencies might be a bit heavier than
7.3.4.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Believe those who are seeking the truth; doubt those who find it...

Fri, 5 Sep 2003 18:53:46 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: 64-bit pgsql
Jeroen Ruigrok/asmodai <asmodai@wxs.nl> writes:
> So it does seem 7.4 places higher demand than 7.3.4 on the SysV IPC,

It should not; there is something wrong here, not merely a documentation
problem.  I am wondering whether your 7.4 build fails to select a TAS()
implementation --- if so, it would fall back to implementing spinlocks
as semaphores, which would translate to a huge increase in the number of
semaphores requested, which would likely result in this symptom.  Can
you strace the postmaster launch and see how many semget()s it does
before dying?

			regards, tom lane

Fri, 05 Sep 2003 13:08:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 64-bit pgsql 
-On [20030905 19:12], Tom Lane (tgl@sss.pgh.pa.us) wrote:
>It should not; there is something wrong here, not merely a documentation
>problem.  I am wondering whether your 7.4 build fails to select a TAS()
>implementation --- if so, it would fall back to implementing spinlocks
>as semaphores, which would translate to a huge increase in the number of
>semaphores requested, which would likely result in this symptom.  Can
>you strace the postmaster launch and see how many semget()s it does
>before dying?

I need to correct one statement Tom, the Athlon box had 3 semaphores in
use by another application.  Which I killed after that.  ipcs then
showed it was not using anything and initdb ran ok.

The Itanium box was also not using any semaphores and failed.

I also did the same on an 5.1-CURRENT Alpha box and it also worked.

So I guess the problem lies in the Itanium port.  Or could I miss
something subtle here?

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Distance lends enhancement to the view...

Fri, 5 Sep 2003 20:31:36 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: 64-bit pgsql
Jeroen Ruigrok/asmodai <asmodai@wxs.nl> writes:
> So I guess the problem lies in the Itanium port.  Or could I miss
> something subtle here?

This strengthens my suspicion that we're not finding TAS code for
the Itanium, but please see if you can strace or ktrace the postmaster
to verify how many semget()s it tries to do.  With max_connections=10
it should really do only one.

Alternatively, find out what symbols your compiler predeclares.
If my theory is right then your pg_config_os.h file is failing to
define HAS_TEST_AND_SET; why?

			regards, tom lane

Fri, 05 Sep 2003 14:48:06 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 64-bit pgsql 
-On [20030905 20:52], Tom Lane (tgl@sss.pgh.pa.us) wrote:
>Alternatively, find out what symbols your compiler predeclares.
>If my theory is right then your pg_config_os.h file is failing to
>define HAS_TEST_AND_SET; why?

Indeed, pg_config_os.h does not set anything for __ia64__.

When I added definitions for Itanium and Opteron to the
src/include/port/freebsd.h (attached) I get the following:

Opteron:

gmake[4]: Entering directory `/h/scratch/asmodai/postgresql-snapshot/src/backend/access/transam'
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o clog.o clog.c
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o transam.o transam.c
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o varsup.o varsup.c
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o xact.o xact.c
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o xlog.o xlog.c
{standard input}: Assembler messages:
{standard input}:7886: Error: Incorrect register `%eax' used with `b' suffix
gmake[4]: *** [xlog.o] Error 1

Itanium:

gmake[4]: Entering directory `/q/scratch/asmodai/postgresql-snapshot/src/backend/access/transam'
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o clog.o clog.c
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o transam.o transam.c
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o varsup.o varsup.c
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o xact.o xact.c
gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o xlog.o xlog.c
../../../../src/include/storage/s_lock.h: In function `tas':
../../../../src/include/storage/s_lock.h:125: error: inconsistent operand constraints in an `asm'
gmake[4]: *** [xlog.o] Error 1

On the Alpha box I get 10 out of 92 regression tests failed, see
http://www.in-nomine.org/~asmodai/regressions.diff

I see some are due to locks failed, but it had as much semaphores
available as the other boxes (or as little) and could go through the
entire initdb routine.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
The wisdom of the wise, and the experience of ages, may be preserved by
quotations...
Fri, 5 Sep 2003 21:41:15 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: 64-bit pgsql
Tom Lane wrote:
> Jeroen Ruigrok/asmodai <asmodai@wxs.nl> writes:
> > So I guess the problem lies in the Itanium port.  Or could I miss
> > something subtle here?
> 
> This strengthens my suspicion that we're not finding TAS code for
> the Itanium, but please see if you can strace or ktrace the postmaster
> to verify how many semget()s it tries to do.  With max_connections=10
> it should really do only one.
> 
> Alternatively, find out what symbols your compiler predeclares.
> If my theory is right then your pg_config_os.h file is failing to
> define HAS_TEST_AND_SET; why?

include/storage/s_lock.h has:

	#if defined(__i386__) || defined(__x86_64__) /* AMD Opteron */

and 

	#if defined(__ia64__) || defined(__ia64)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 5 Sep 2003 17:00:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 64-bit pgsql
Jeroen Ruigrok/asmodai wrote:
> -On [20030905 20:52], Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >Alternatively, find out what symbols your compiler predeclares.
> >If my theory is right then your pg_config_os.h file is failing to
> >define HAS_TEST_AND_SET; why?
> 
> Indeed, pg_config_os.h does not set anything for __ia64__.
> 
> When I added definitions for Itanium and Opteron to the
> src/include/port/freebsd.h (attached) I get the following:

This post brings up a problem with our configuration system.  Right now,
we test for compiler flags and set HAS_TEST_AND_SET based on the CPU in
each include/port/{os}.h file.  However, this requires us to know about
each CPU enabled on each OS, and requires us to add duplicate
CPU-specific code for each platform.  See below for FreeBSD:

	--- freebsd.h.orig	Fri Sep  5 21:38:06 2003
	+++ freebsd.h	Fri Sep  5 21:41:38 2003
	@@ -44,5 +44,14 @@
	 #if defined(__powerpc__)
	 #define HAS_TEST_AND_SET
	 typedef unsigned int slock_t;
	+#endif
	 
	+#if defined(__ia64__)
	+#define HAS_TEST_AND_SET
	+typedef unsigned int slock_t;
	+#endif
	+
	+#if defined(__x64_64__)
	+#define HAS_TEST_AND_SET
	+typedef unsigned int slock_t;
	 #endif

For example, we will need the last two defines for all platforms that
support Intel.  I wonder if we should have the HAS_TEST_AND_SET defined
in s_lock.h where the actual test-and-set is defined.  This would
eliminate redundancy, and fix the FreeBSD problem reported with
Opteron/Itanium.  I think we still need an slock_t typedef, but it is
probably the same for all CPU's on that platform.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 10 Sep 2003 18:32:27 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 64-bit pgsql

You should find that the next daily snapshot and beta3 will properly
detect Opteron/Itanium on your platform.

I don't think we can help you with the compiler bugs, however.  ;-)

---------------------------------------------------------------------------

Jeroen Ruigrok/asmodai wrote:
> -On [20030905 20:52], Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >Alternatively, find out what symbols your compiler predeclares.
> >If my theory is right then your pg_config_os.h file is failing to
> >define HAS_TEST_AND_SET; why?
> 
> Indeed, pg_config_os.h does not set anything for __ia64__.
> 
> When I added definitions for Itanium and Opteron to the
> src/include/port/freebsd.h (attached) I get the following:
> 
> Opteron:
> 
> gmake[4]: Entering directory `/h/scratch/asmodai/postgresql-snapshot/src/backend/access/transam'
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o clog.o clog.c
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o transam.o transam.c
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o varsup.o varsup.c
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o xact.o xact.c
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o xlog.o xlog.c
> {standard input}: Assembler messages:
> {standard input}:7886: Error: Incorrect register `%eax' used with `b' suffix
> gmake[4]: *** [xlog.o] Error 1
> 
> Itanium:
> 
> gmake[4]: Entering directory `/q/scratch/asmodai/postgresql-snapshot/src/backend/access/transam'
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o clog.o clog.c
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o transam.o transam.c
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o varsup.o varsup.c
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o xact.o xact.c
> gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c -o xlog.o xlog.c
> ../../../../src/include/storage/s_lock.h: In function `tas':
> ../../../../src/include/storage/s_lock.h:125: error: inconsistent operand constraints in an `asm'
> gmake[4]: *** [xlog.o] Error 1
> 
> On the Alpha box I get 10 out of 92 regression tests failed, see
> http://www.in-nomine.org/~asmodai/regressions.diff
> 
> I see some are due to locks failed, but it had as much semaphores
> available as the other boxes (or as little) and could go through the
> entire initdb routine.
> 
> -- 
> Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
> PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
> http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
> The wisdom of the wise, and the experience of ages, may be preserved by
> quotations...

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 12 Sep 2003 12:13:58 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 64-bit pgsql