Thread: postgresql with gcc on dec aplha osf

postgresql with gcc on dec aplha osf

From
Thomas Boos
Date:
hello,

i'm using postgresql 6.5.3 on a dec alpha.
i have tried to compile it with gcc and ran into many errors.
after i have inspected some of these errors, it seems, that
there is a problem with the s_lock (semaphore, shared memory).
some hours later, i have found some interesting definitions,
which let me come to the conclution, that this version of
postgresql could never be compiled on a dec alpha with gcc.

the bug is in postgresql-6.5.3/src/include/os.h
which is a link to postgresql-6.5.3/src/include/port/alpha.h
in relation to postgresql-6.5.3/src/include/storage/s_lock.h.

there is the following problem:

os.h says:

typedef msemaphore slock_t;

and msemaphore (from <sys/mman.h>) is:

typedef struct {
        int msem_state;
        int msem_wanted;
} msemaphore;

which means, it is a aggregation.

if we look on the lines 81 - 107 from the file s_lock.h we could
see the definitions for alpha (__alpha__) with gcc (__GNUC__).
there is following line:

#define S_UNLOCK(lock) {__asm__("mb"); *(lock) = 0; }

but there is no definition of S_INIT_LOCK, which means that the
definition in the lines 380 - 382 will be used:

#define S_INIT_LOCK(lock)       S_UNLOCK(lock)

ok. so far so good (or not :) ).

then we should take a look into
postgresql-6.5.3/src/backend/storage/buffer/buf_init.c
to the line 219:

                S_INIT_LOCK(&(buf->io_in_progress_lock));

definition of buf:

        BufferDesc *buf;

definition of BufferDesc (in file
postgresql-6.5.3/src/include/storage/buf_internals.h):

typedef struct sbufdesc BufferDesc;

in sbufdesc is io_in_progress_lock defined as (line 101):

        slock_t io_in_progress_lock;

when i replace the variable by its type (surrounded by $), i
will get the following line:

        S_INIT_LOCK(&($slock_t$));

now, lets use our brain and we will get:

        {__asm__("mb"); *($msemaphore$) = 0; }

wow, its a nice thing, but the compiler doesn't like things such
this ones.
you can't assign something to a structure!

after some more investigation i discoverd, that there is a semaphore
mechanism, which will be used, if we compile with the normal cc.
but someone has the opinion, that we can't use this mechanism, when
we want to use gcc. ok, i won't doubt it, but he has forgotten to
replace msemaphore with a simple long.
this means, imho postgresql-6.5.3/src/include/port/alpha.h should look
like this:

     1  #define USE_POSIX_TIME
     2  #define DISABLE_XOPEN_NLS
     3  #define HAS_TEST_AND_SET
     4  #include <sys/mman.h>                   /* for msemaphore */
     5
     6  #if defined(__GNUC__)
     7  typedef long slock_t;
     8  #else
     9  typedef msemaphore slock_t;
    10  #endif
    11
    12  /* some platforms define __alpha, but not __alpha__ */
    13  #if defined(__alpha) && !defined(__alpha__)
    14  #define __alpha__
    15  #endif

ok, thats all.
after "make all", "make install" and a initdb, everything works fine.
i could do a regression test and the results looks good. (only a few
failure,
look at the attachment)
i hope, i'm not wrong and i could help someone.

thanks for your patience... :)
--
MfG
Thomas Boos
Diplom Informatiker

DaimlerChrysler Aerospace  Verteidigung und Zivile Systeme
                           Defense and Civil Systems

Knowledge Based Systems Engineering
Command Control Communications Intelligence

VCE13                                Fax: +49 89 3179 2893
Landshuter Str. 26                   Tel: +49 89 3179 3231
85716 Unterschleissheim=============== Notes...                              =================
postmaster must already be running for the regression tests to succeed.
The time zone is now set to PST8PDT explicitly by this regression test
 client frontend. Please report any apparent problems to
   ports@postgresql.org
See regress/README for more information.

=============== destroying old regression database... =================
ERROR:  destroydb: database 'regression' does not exist
destroydb: database destroy failed on regression.
=============== creating new regression database...   =================
=============== installing PL/pgSQL...                =================
=============== running regression queries...         =================
boolean ..  ok
char ..  ok
name ..  ok
varchar ..  ok
text ..  ok
strings ..  ok
int2 ..  ok
int4 ..  ok
int8 ..  ok
oid ..  ok
float4 ..  ok
float8 ..  failed
numerology ..  ok
point ..  ok
lseg ..  ok
box ..  ok
path ..  ok
polygon ..  ok
circle ..  ok
geometry ..  failed
timespan ..  ok
datetime ..  ok
reltime ..  ok
abstime ..  failed
tinterval ..  failed
horology ..  failed
inet ..  ok
comments ..  ok
oidjoins ..  ok
type_sanity ..  ok
opr_sanity ..  ok
create_function_1 ..  ok
create_type ..  ok
create_table ..  ok
create_function_2 ..  ok
constraints ..  ok
triggers ..  ok
copy ..  ok
create_misc ..  ok
create_aggregate ..  ok
create_operator ..  ok
create_view ..  ok
create_index ..  ok
sanity_check ..  ok
errors ..  ok
select ..  ok
select_into ..  ok
select_distinct ..  ok
select_distinct_on ..  ok
select_implicit ..  ok
select_having ..  ok
subselect ..  ok
union ..  ok
case ..  ok
join ..  ok
aggregates ..  ok
transactions ..  ok
random ..  ok
portals ..  ok
misc ..  ok
arrays ..  ok
btree_index ..  ok
hash_index ..  ok
select_views ..  ok
alter_table ..  ok
portals_p2 ..  ok
rules ..  failed
limit ..  ok
plpgsql ..  ok
temp ..  ok
numeric ..  ok

Re: postgresql with gcc on dec aplha osf

From
Adriaan Joubert
Date:
Yes, it doesn't compile. use cc with template alpha_cc, which works fine. It
uses semaphores for locking, which is slow, but works. Somebody is working on
assembler for s_lock. Ryan Kirkpatrick has got a set of patches for (linux)
alpha+gcc -- search the mailing lists, as i do not have a link to his
website. Note that questions have been raised as to whether the assembler in
the gcc section for alphas is reliable on SMP boxes -- nobody here seems to
know alphas+alpha assembler well enough to answer that one conclusively ;-(.

Adriaan