Thread: 64-bit pgsql
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
> 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.
-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...
-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...
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.
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
-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...
-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...
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
-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...
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
-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
-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...
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
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, Pennsylvania19073
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+typedefunsigned int slock_t;+#endif++#if defined(__x64_64__)+#define HAS_TEST_AND_SET+typedef unsigned
intslock_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,
Pennsylvania19073
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,
Pennsylvania19073