bionic (5) lmdb_table.5.gz

Provided by: postfix-lmdb_3.3.0-1ubuntu0.4_amd64 bug

NAME

       lmdb_table - Postfix LMDB adapter

SYNOPSIS

       postmap lmdb:/etc/postfix/filename
       postmap -i lmdb:/etc/postfix/filename <inputfile

       postmap -d "key" lmdb:/etc/postfix/filename
       postmap -d - lmdb:/etc/postfix/filename <inputfile

       postmap -q "key" lmdb:/etc/postfix/filename
       postmap -q - lmdb:/etc/postfix/filename <inputfile

DESCRIPTION

       The  Postfix  LMDB adapter provides access to a persistent, memory-mapped, key-value store.  The database
       size is limited only by the size of the memory address space (typically 31 or 47 bits on 32-bit or 64-bit
       CPUs, respectively) and by the available file system space.

REQUESTS

       The  LMDB  adapter  supports  all  Postfix lookup table operations.  This makes LMDB suitable for Postfix
       address rewriting, routing, access policies, caches, or any information that can be stored under a  fixed
       lookup key.

       When  a  transaction  fails  due  to  a  full  database,  Postfix  resizes  the  database and retries the
       transaction.

       Postfix table lookups may generate partial  search  keys  such  as  domain  names  without  one  or  more
       subdomains,  network  addresses  without one or more least-significant octets, or email addresses without
       the localpart, address extension or domain portion.  This behavior  is  also  found  with,  for  example,
       btree:, hash:, or ldap: tables.

       Unlike  other  flat-file  Postfix  databases, changes to an LMDB database do not trigger automatic daemon
       program restart, and do not require "postfix reload".

RELIABILITY

       LMDB's copy-on-write architecture provides safe updates, at the cost of using more space than some  other
       flat-file   databases.    Read  operations  are  memory-mapped  for  speed.   Write  operations  are  not
       memory-mapped to avoid silent corruption due to stray pointer bugs.

       Multiple processes  can  safely  update  an  LMDB  database  without  serializing  requests  through  the
       proxymap(8) service.  This makes LMDB suitable as a shared cache for verify(8) or postscreen(8) services.

SYNCHRONIZATION

       The  Postfix  LMDB  adapter  does  not  use  LMDB's  built-in  locking scheme, because that would require
       world-writable lockfiles and would violate the Postfix security model.  Instead,  Postfix  uses  fcntl(2)
       locks  with  whole-file  granularity.   Programs that use LMDB's built-in locking protocol will corrupt a
       Postfix LMDB database or will read garbage.

       Every Postfix LMDB database read or write transaction must be protected from start to end with  a  shared
       or exclusive fcntl(2) lock.  A writer may atomically downgrade an exclusive lock to a shared lock, but it
       must hold an exclusive lock while opening another write transaction.

       Note that fcntl(2) locks do not protect transactions within the same process against each  other.   If  a
       program  cannot  avoid  making simultaneous database requests, then it must protect its transactions with
       in-process locks, in addition to the per-process fcntl(2) locks.

CONFIGURATION PARAMETERS

       Short-lived programs automatically pick up changes to main.cf.  With long-running  daemon  programs,  Use
       the command "postfix reload" after a configuration change.

       lmdb_map_size (default: 16777216)
              The initial LMDB database size limit in bytes.

SEE ALSO

       postconf(1), Postfix supported lookup tables
       postmap(1), Postfix lookup table maintenance
       postconf(5), configuration parameters

README FILES

       Use "postconf readme_directory" or "postconf html_directory" to locate this information.
       DATABASE_README, Postfix lookup table overview
       LMDB_README, Postfix OpenLDAP LMDB howto

LICENSE

       The Secure Mailer license must be distributed with this software.

HISTORY

       LMDB support was introduced with Postfix version 2.11.

AUTHOR(S)

       Howard Chu
       Symas Corporation

       Wietse Venema
       IBM T.J. Watson Research
       P.O. Box 704
       Yorktown Heights, NY 10598, USA

       Wietse Venema
       Google, Inc.
       111 8th Avenue
       New York, NY 10011, USA

                                                                                                   LMDB_TABLE(5)