Provided by: postfix-lmdb_3.8.6-1build2_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.

       Changes to an LMDB database do not trigger an automatic daemon restart,  and  do  not  require  a  daemon
       restart with "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 (16777216)
              The initial OpenLDAP 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)