I haven't been following this thread. Can someone answer:
Is TLB Linux-only? Why use it and non SysV memory? Is it a lot of code? --------------------------------------------------------------------------- Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > If we used a key that would remain the same between runs of the > > postmaster, this should ensure that there isn't a possibility of two > > independant sets of backends operating on the same data dir. The most > > logical way to do this IMHO would be to just hash the data dir, but I > > suppose the current method of using the port number should work as > > well. > > You should stick as closely as possible to the key logic currently used > for SysV shmem keys. That logic is intended to cope with the case where > someone else is already using the key# that we initially generate, as > well as the case where we discover a collision with a pre-existing > backend set. (We tell the difference by looking for a magic number at > the start of the shmem segment.) > > Note that we do not assume the key is the same on each run; that's why > we store it in postmaster.pid. > > > (1) call sys_alloc_hugepages() without IPC_EXCL. If it returns > > an error, we're in the clear: there's no page matching > > that key. If it returns a pointer to a previously existing > > segment, panic: it is very likely that there are some > > orphaned backends still active. > > s/panic/and the PG magic number appears in the segment header, panic/ > > > - if we're compiling on a Linux system but the kernel headers > > don't define the syscalls we need, use some reasonable > > defaults (e.g. the syscall numbers for the current hugepage > > syscalls in Linux 2.5) > > I think this is overkill, and quite possibly dangerous. If we don't see > the symbols then don't try to compile the code. > > On the whole it seems that this allows a very nearly one-to-one mapping > to the existing SysV functionality. We don't have the "number of > connected processes" syscall, perhaps, but we don't need it: if a > hugepages segment exists we can assume the number of connected processes > is greater than 0, and that's all we really need to know. > > I think it's okay to stuff this support into the existing > port/sysv_shmem.c file, rather than make a separate file (particularly > given your point that we have to be able to fall back to SysV calls at > runtime). I'd suggest reorganizing the code in that file slightly to > separate the actual syscalls from the controlling logic in > PGSharedMemoryCreate(). Probably also will have to extend the API for > PGSharedMemoryIsInUse() and RecordSharedMemoryInLockFile() to allow > three fields to be recorded in postmaster.pid, not two --- you'll want > a boolean indicating whether the stored key is for a SysV or hugepage > segment. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]