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]

Reply via email to