"Luis Alberto Amigo Navarro" <lamigo@atc.unican.es> writes:
> if you want postgres to run fine on this machines I think (it's not tested
> yet) it would be neccesary to implement native shared arenas instead of IPC
> shared memory in order to let IRIX make a fine load-balance.
In CVS tip, the direct dependencies on SysV shared-memory calls have
been split into a separate file, src/backend/port/sysv_shmem.c. It
would not be difficult to make a crude port to some other shared-memory
API, if you want to do some performance testing.
A not-so-crude port would perhaps be more difficult. One thing that we
depend on is being able to detect whether old backends are still running
in a particular database cluster (this could happen if the postmaster
itself crashes, leaving orphaned backends behind). Currently this is
done by recording the shmem key in the postmaster's lockfile, and then
during restart looking to see if any process is still attached to that
shmem segment. So we are relying on the fact that SysV shmem segments
(a) are not anonymous, and (b) accept a syscall to find out whether any
other processes are attached to them. If the shared-memory API you want
to use doesn't support similar capabilities, then there's a problem.
You might be able to think of a different way to provide the same kind
of interlock, though.
> I take advantage of this message to say that there is a cuple of things that
> we have to insert on FAQ-IRIX about using 32 bits or 64 bits objects,
Send a patch ;-)
regards, tom lane