Vadim Mikheev <vadim@krs.ru> writes:
> Also, all this ShmemIndex stuff seems to be useless
> (except of backend PID lookup but it's for sure
> should be in separate hash table).
Have I got a deal for you ;-). I have uncommitted changes that add
a pointer (SHMEM_OFFSET that is) to each backend's PROC struct into
the per-backend info array that already existed in shmem.c. The
routines in shmem.c that searched for PROC structures are now in
sinval.c, and just do a simple scan of the ProcState array to find
the PROC structs. They should be a whole lot faster --- which is
good since these things run with spinlocks held...
These changes are intermixed with other things that are currently
triggering a lot of NOTICE: Buffer Leak messages in the regress tests,
so I don't want to commit until I've puzzled out the buffer refcount
issue. But I've got 'em and they seem to work fine.
> And why separate shmem segment (!!!) is used for
> Slocks (ipc.c:CreateAndInitSLockMemory(), etc) - they
> use so small amount of memory!
Historical reasons I suppose. shmem.c does assume that spinlocks
are already up and running when it is initialized, so combining
everything into one segment would require care. But it's surely
doable if someone wants to take the time. (I don't.)
regards, tom lane