Re: [HACKERS] Alpha initdb fixed!

On Tue, 17 Mar 1998, Pedro J. Lobo wrote:

>On Mon, 16 Mar 1998, Dwayne Bailey wrote:
>
>>I've gotten 6.3 initdb to run to a successful completion on my
>>Alpha running OSF/1 V3.2c. Forget the change that I sent in
>>earlier. While I still think that there's something funky with
>>that code, it doesn not need to be modifed. Actually, the
>>modifications are miniscule. The only files that need to be
>>changed are backend/main/main.c and template/alpha.
>>
>>The real trick is to add -Dalpha to the CFLAGS setting. The
>>changes to main.c are only to add some extra includes to support
>>some code that's suddenly being used.
>>
>>The #define ASSEMBLER is to prevent most of the code of
>>sys/proc.h from being included, as it ends up conflicting with
>>some of the postgresql definitions. This may or may not work on
>>other versions of Digital Unix.
>
>I'll try it immediately, but I have a suggestion. On my DU 3.2c system, cc
>defines automatically the symbols "__osf__" and "__alpha", and gcc defines
>"__osf__", "__alpha" and "__alpha__". I think it would be easier to change
>every "#ifdef alpha" to "#ifdef __alpha", and stop worrying about it in
>the Makefiles.

I've just tried it, and it works partially. The initdb works fine, so I've
tried to run the regression tests. Here is the output:

==============================================================
boolean .. ok
char .. ok
char2 .. ok
char4 .. ok
char8 .. ok
char16 .. ok
varchar .. ok
text .. ok
strings .. ok
int2 .. failed
int4 .. failed
oid .. ok
oidint2 .. failed
oidint4 .. failed
oidname .. failed
[...]
==============================================================

All tests after oid fail, because the postmaster dies with this message:

========================
[...]
ERROR: pg_atoi: error reading "123456": Result too large
ERROR: pg_atoi: error in "asdfasd": can't parse "asdfasd"
semget: No space left on device
This type of error is usually caused by improper
shared memory or System V IPC semaphore configuration.
See the FAQ for more detailed information
FATAL 1: AttachSLockMemory: could not attach segment
=========================

Running the regression test after starting the postmaster with "-d 2"
gives:

========================
[...]
/usr/local/pgsql.beta/bin/postmaster child[0]:
execv(/usr/local/pgsql.beta/bin/postgres, -p, -d2, -P4, -F, -e, -B, 256, -v 65536, regression, )
/usr/local/pgsql.beta/bin/postmaster: BackendStartup: pid 6011 user pgbeta
db regression socket 4
FindBackend: found "/usr/local/pgsql.beta/bin/postgres" using argv[0]
binding ShmemCreate(key=0, size=2414376)
semget: No space left on device
This type of error is usually caused by improper
shared memory or System V IPC semaphore configuration.
See the FAQ for more detailed information
---debug info---
Quiet = f
Noversion = f
timings = f
dates = European
bufsize = 256
sortmem = 512
query echo = f
DatabaseName = [regression]
----------------

InitPostgres()..
/usr/local/pgsql.beta/bin/postmaster: reaping dead processes...
/usr/local/pgsql.beta/bin/postmaster: CleanupProc: pid 6011 exited with
status 768
/usr/local/pgsql.beta/bin/postmaster: CleanupProc: reinitializing shared
memory and semaphores
FATAL 1: AttachSLockMemory: could not attach segment
===========================

I am using these options (they worked fine with 6.2.1 and 6.2.1p6):

postmaster -d 2 -o '-F -e' -B 256 -D/usr/local/pgsql.beta/data

Also, after the postmaster dies I have to manually remove (using ipcrm) 15
semaphores and one shared memory area. Since there is one more semaphore
owned by root, there are 16 semaphores allocated when the postmaster dies.
I have looked at my system configuration, and that's the system limit. I
can raise it to, say, 32, but the 6.2.1 system worked fine with my current
configuration. I suspect that the postmaster is allocating semaphores and
never releasing them.

Any hints?

-------------------------------------------------------------------
Pedro José Lobo Perea Tel: +34 1 336 78 19
Centro de Cálculo Fax: +34 1 331 92 29
EUIT Telecomunicación - UPM e-mail: pjlobo(at)euitt(dot)upm(dot)es