Bugfix: an error handler for smtp_tls_policy_maps lookups
was never invoked. File: smtp/smtp_session.c.
+20130212
+
+ Cleanup: logfile message formatting (X: subject_CN=X,
+ issuer_CN=X, fingerprint=X, pkey_fingerprint=X). File:
+ tls/tls_client.c.
+
20130315
Feature: preliminary LMDB (memory-mapped persistent file)
- support by Howard Chu. This feature has a number of unexpected
- limitations and is therefore "snapshot only", i.e. it will
- not be part of a stable release. Files: proto/postconf.proto,
+ support by Howard Chu. This feature has unexpected limitations
+ that don't exist with other Postfix databases, and is
+ therefore "snapshot only", i.e. it will not be part of a
+ stable release without further changes to the Postfix LMDB
+ client or the Postfix dictionary API. Files: proto/postconf.proto,
proto/LMDB_README.html, proto/DATABASE_README.html,
- util/dict_lmdb.[hc], util/dict_open.c, global/mkmap_lmdb.[hc],
- global/mkmap_open.c, postconf/postconf.c.
+ proto/INSTALL.html util/dict_lmdb.[hc], util/dict_open.c,
+ global/mkmap_lmdb.[hc], global/mkmap_open.c, postconf/postconf.c.
* DB_README: Berkeley DB Howto
* CDB_README: CDB Howto
* LDAP_README: LDAP Howto
+ * LMDB_README: LMDB Howto
* MEMCACHE_README: Memcache Howto
* MYSQL_README: MySQL Howto
* PCRE_README: PCRE Howto
3. Missing pthread library trouble.
- Caution: the current Postfix LMDB client has unexpected limitations. For
- this reason, LMDB support is not part of the stable Postfix release.
+Caution:
+ The current Postfix LMDB client has unexpected limitations that don't exist
+ with other Postfix databases. For this reason, LMDB support will not be
+ part of the stable Postfix release without further changes to the Postfix
+ LMDB client or the Postfix dictionary API.
B\bBu\bui\bil\bld\bdi\bin\bng\bg P\bPo\bos\bst\btf\bfi\bix\bx w\bwi\bit\bth\bh O\bOp\bpe\ben\bnL\bLD\bDA\bAP\bP L\bLM\bMD\bDB\bB s\bsu\bup\bpp\bpo\bor\brt\bt
L\bLi\bim\bmi\bit\bta\bat\bti\bio\bon\bns\bs o\bof\bf P\bPo\bos\bst\btf\bfi\bix\bx L\bLM\bMD\bDB\bB d\bda\bat\bta\bab\bba\bas\bse\bes\bs.\b.
- * U\bUn\bne\bex\bxp\bpe\bec\bct\bte\bed\bd p\bpo\bos\bst\btm\bma\bap\bp/\b/p\bpo\bos\bst\bta\bal\bli\bia\bas\bs "\b"d\bda\bat\bta\bab\bba\bas\bse\be f\bfu\bul\bll\bl"\b" e\ber\brr\bro\bor\brs\bs.\b.
+U\bUn\bne\bex\bxp\bpe\bec\bct\bte\bed\bd p\bpo\bos\bst\btm\bma\bap\bp(\b(1\b1)\b)/\b/p\bpo\bos\bst\bta\bal\bli\bia\bas\bs(\b(1\b1)\b) "\b"d\bda\bat\bta\bab\bba\bas\bse\be f\bfu\bul\bll\bl"\b" e\ber\brr\bro\bor\brs\bs.\b.
- Even if the "postmap filename" command succeeds, the exact same command,
- with the exact same input data, may fail subsequently with an MDB_MAP_FULL
- error. The reason is that unlike other Postfix databases such as "hash" or
- "btree",
+Problem:
+ Even if the "postmap lmdb:filename" command succeeds, the exact same
+ command (with the exact same input data) may fail subsequently with an
+ MDB_MAP_FULL error. This problem does not exist with other Postfix
+ databases.
- o LMDB databases have a hard size limit (configured with the
- lmdb_map_size configuration parameter).
+Background:
+ LMDB databases have a hard size limit (configured with the lmdb_map_size
+ configuration parameter).
- o The Postfix LMDB database client does not implement the "truncate"
- operation. Instead it saves all store requests to a transaction (which
- takes up space in addition to the existing data), and commits the
- transaction when the database is closed. Only then can the space for
- old data be reused.
+ When executing "postmap lmdb:filename", the Postfix LMDB database client
+ does not truncate the database file. Instead it saves the "drop" request
+ and subsequent "store" requests to a transaction (which takes up space in
+ addition to the existing data), and commits the transaction when it closes
+ the database. Only then can the space for old data be reused.
- This postmap(1) or postalias(1) command failure does not affect Postfix
- availability, because the old data still exists in the database.
+Impact:
+ This failure does not affect Postfix availability, because the old data
+ still exists in the database.
- To recover, increase the lmdb_map_size limit in main.cf, and retry the
- postmap(1) or postalias(1) command.
+Recovery:
+ Increase the lmdb_map_size limit in main.cf, and retry the postmap(1) or
+ postalias(1) command.
+
+P\bPo\bos\bst\btf\bfi\bix\bx d\bda\bae\bem\bmo\bon\bn "\b"d\bda\bat\bta\bab\bba\bas\bse\be f\bfu\bul\bll\bl"\b" e\ber\brr\bro\bor\brs\bs.\b.
- * P\bPo\bos\bst\btf\bfi\bix\bx d\bda\bae\bem\bmo\bon\bn "\b"d\bda\bat\bta\bab\bba\bas\bse\be f\bfu\bul\bll\bl"\b" e\ber\brr\bro\bor\brs\bs.\b.
+Problem:
+ "database full" errors with daemon programs such as postscreen(8), tlsmgr
+ (8) or verify(8). This problem does not exist with other Postfix databases.
- Unfortunately, "database full" problems will affect Postfix availability
- with daemon programs such as postscreen(8), tlsmgr(8) or verify(8). These
- daemon programs will continue to fail until someone increases the
- lmdb_map_size parameter value. Meanwhile, mail processing comes to a halt.
+Impact:
+ Postfix does not process mail until someone fixes the problem.
- * N\bNo\bon\bn-\b-o\bob\bbv\bvi\bio\bou\bus\bs r\bre\bec\bco\bov\bve\ber\bry\by f\bfr\bro\bom\bm a\ba c\bco\bor\brr\bru\bup\bpt\bte\bed\bd d\bda\bat\bta\bab\bba\bas\bse\be.\b.
+Recovery:
+ Increase the lmdb_map_size limit in main.cf, and "reload" Postfix.
- Unlike other Postfix databases such as "hash" or "btree", you can't rebuild
- a corrupted LMDB database simply by running postmap(1) or postalias(1), as
- those commands will crash, too.
+N\bNo\bon\bn-\b-o\bob\bbv\bvi\bio\bou\bus\bs r\bre\bec\bco\bov\bve\ber\bry\by w\bwi\bit\bth\bh p\bpo\bos\bst\btm\bma\bap\bp(\b(1\b1)\b)/\b/p\bpo\bos\bst\bta\bal\bli\bia\bas\bs(\b(1\b1)\b) f\bfr\bro\bom\bm a\ba c\bco\bor\brr\bru\bup\bpt\bte\bed\bd d\bda\bat\bta\bab\bba\bas\bse\be.\b.
+Problem:
+ You cannot rebuild a corrupted LMDB database simply by running postmap(1)
+ or postalias(1). This problem does not exist with other Postfix databases.
+
+Background:
The reason for this limitation is that the Postfix LMDB database client
- does not implement the database "truncate" operation. Instead it tries to
- save all store requests to a transaction for later processing. That is
- obviously not possible with a corrupted database file.
-
- To recover, you must first delete the ".lmdb" file by hand, and only then
- you can retry the postmap(1) or postalias(1) command.
-
- * I\bIn\bnc\bco\bom\bmp\bpa\bat\bti\bib\bbi\bil\bli\bit\bty\by w\bwi\bit\bth\bh t\btl\bls\bsm\bmg\bgr\br(\b(8\b8)\b).\b.
-
- The Postfix LMDB database client breaks tlsmgr(8) TLS session cache
- management. Specifically, it breaks how tlsmgr(8) clears its TLS session
- cache databases upon start-up, it breaks how tlsmgr(8) looks up new TLS
- session cache entries, and it breaks how tlsmgr(8) automatically recovers
- from a corrupted database file.
-
- The reason for these limitations is that the Postfix LMDB database client
- does not implement the database "truncate" operation. Instead it saves all
- store requests to a transaction which it commits only when the database is
- closed. Therefore, tlsmgr(8) will never find any entries that it stores
- after opening its TLS session cache databases. And when the database
- becomes corrupted, tlsmgr(8) will keep crashing until someone removes the
- file ".lmdb" file by hand.
+ does not truncate the database file. Instead it attempts to save the "drop"
+ request and subsequent "store" requests to a transaction for later
+ processing. That is obviously not possible with a corrupted database file.
+
+Recovery:
+ First delete the ".lmdb" file by hand, then rebuild the file with the
+ postmap(1) or postalias(1) command.
+
+I\bIn\bnc\bco\bom\bmp\bpa\bat\bti\bib\bbi\bil\bli\bit\bty\by w\bwi\bit\bth\bh t\btl\bls\bsm\bmg\bgr\br(\b(8\b8)\b).\b.
+
+Problem:
+ The Postfix LMDB database client never commits any tlsmgr(8) transaction.
+ This problem does not exist with other Postfix databases.
+
+Background:
+ Instead, it creates a single transaction that accumulates a "drop" request
+ and all tlsmgr(8) "store" requests that are made during the lifetime of the
+ process.
+
+Solution:
+ This requires changes to the Postfix dictionary API, or to the Postfix LMDB
+ database client.
+
+Problem:
+ The Postfix LMDB database client breaks how tlsmgr(8) automatically
+ recovers from a corrupted database file. This problem does not exist with
+ other Postfix databases.
+
+Background:
+ The Postfix LMDB database client does not truncate the database file.
+ Instead it attempts to create a transaction which obviously is not possible
+ when the database file is corrupted.
+
+Impact:
+ The tlsmgr(8) process will keep crashing until someone removes the ".lmdb"
+ file.
+
+Recovery:
+ Remove the the ".lmdb" file by hand, and wait until the tlsmgr(8) process
+ restarts.
Major changes with snapshot 20130315
====================================
-Perliminary LMDB support by Howard Chu. This implementation has
-unexpected limitations that make it a poor fit, and for this reason
-the code is "snapshot only", i.e. it will not be part of the stable
-release. See LMDB_README for details.
+Preliminary LMDB support by Howard Chu. This implementation has
+unexpected limitations that don't exist with other Postfix databases,
+and therefore the code is "snapshot only", i.e. it will not be part
+of the stable release without further changes to the Postfix LMDB
+client or the Postfix dictionary API. See LMDB_README for details.
Spellcheck and double-word check.
+ It would be nice if the result from one table lookup could
+ serve as input for another (e.g. virtual aliases before the
+ list of valid recipients). For this to work the magical
+ (bare user, domain only, etc.) lookups need to become a
+ table property, not a property of the client context.
+
+ It would be nice if "bare username" lookup is not hard-coded
+ for domains in the local address class.
+
Don't forget Apple's code donation for fetching mail from
IMAP server.
</ol>
-<blockquote> <p> Caution: the current Postfix LMDB client has <a
-href="#limitations">unexpected limitations</a>. For this reason,
-LMDB support is not part of the stable Postfix release. </p>
-</blockquote>
+<dl> <dt> Caution: </dt> <dd> <p> The current Postfix LMDB client
+has <a href="#limitations">unexpected limitations</a> that don't
+exist with other Postfix databases. For this reason, LMDB support
+will not be part of the stable Postfix release without further
+changes to the Postfix LMDB client or the Postfix dictionary API.
+</p> </dd> </dl>
<h2><a name="with_lmdb">Building Postfix with OpenLDAP LMDB support</a></h2>
More information is available at
<a href="http://highlandsun.com/hyc/mdb/">http://highlandsun.com/hyc/mdb/</a>. </p>
-<h2><a name="limitations">Limitations of Postfix LMDB databases. </a> </h2>
-
-<ul>
+<h2><a name="limitations">Limitations of Postfix LMDB databases.
+</a> </h2>
-<li> <p> <strong>Unexpected postmap/postalias "database full" errors.
+<p> <strong>Unexpected <a href="postmap.1.html">postmap(1)</a>/<a href="postalias.1.html">postalias(1)</a> "database full" errors.
</strong></p>
-<p> Even if the "postmap filename" command succeeds, the exact same
-command, with the exact same input data, may fail subsequently with
-an MDB_MAP_FULL error. The reason is that unlike other Postfix
-databases such as "hash" or "btree", </p>
+<dl>
-<ul>
+<dt> Problem: </dt> <dd> <p> Even if the "postmap <a href="LMDB_README.html">lmdb</a>:filename"
+command succeeds, the exact same command (with the exact same input
+data) may fail subsequently with an MDB_MAP_FULL error. This problem
+does not exist with other Postfix databases. </p> </dd>
-<li> <p> LMDB databases have a hard size limit (configured with the
+<dt> Background: </dt>
+
+<dd>
+
+<p> LMDB databases have a hard size limit (configured with the
<a href="postconf.5.html#lmdb_map_size">lmdb_map_size</a> configuration parameter). </p>
-<li> <p> The Postfix LMDB database client does not implement the
-"truncate" operation. Instead it saves all store requests to a
-transaction (which takes up space in addition to the existing data),
-and commits the transaction when the database is closed. Only then
-can the space for old data be reused. </p>
+<p> When executing "postmap <a href="LMDB_README.html">lmdb</a>:filename", the Postfix LMDB database
+client does not truncate the database file. Instead it saves the
+"drop" request and subsequent "store" requests to a transaction
+(which takes up space in addition to the existing data), and commits
+the transaction when it closes the database. Only then can the
+space for old data be reused. </p>
-</ul>
+</dd>
-<p> This <a href="postmap.1.html">postmap(1)</a> or <a href="postalias.1.html">postalias(1)</a> command failure does not affect
-Postfix availability, because the old data still exists in the
-database. </p>
+<dt> Impact: </dt> <dd> <p> This failure does not affect Postfix
+availability, because the old data still exists in the database.
+</p> </dd>
-<p> To recover, increase the <a href="postconf.5.html#lmdb_map_size">lmdb_map_size</a> limit in <a href="postconf.5.html">main.cf</a>, and
-retry the <a href="postmap.1.html">postmap(1)</a> or <a href="postalias.1.html">postalias(1)</a> command. </p>
+<dt> Recovery: </dt> <dd> <p> Increase the <a href="postconf.5.html#lmdb_map_size">lmdb_map_size</a> limit in
+<a href="postconf.5.html">main.cf</a>, and retry the <a href="postmap.1.html">postmap(1)</a> or <a href="postalias.1.html">postalias(1)</a> command. </p>
+</dd>
-<li> <p> <strong>Postfix daemon "database full" errors. </strong></p>
+</dl>
-<p> Unfortunately, "database full" problems will affect Postfix
-availability with daemon programs such as <a href="postscreen.8.html">postscreen(8)</a>, <a href="tlsmgr.8.html">tlsmgr(8)</a>
-or <a href="verify.8.html">verify(8)</a>. These daemon programs will continue to fail until
-someone increases the <a href="postconf.5.html#lmdb_map_size">lmdb_map_size</a> parameter value. Meanwhile,
-mail processing comes to a halt. </p>
+<p> <strong>Postfix daemon "database full" errors. </strong></p>
-<li> <p> <strong>Non-obvious recovery from a corrupted database.
-</strong></p>
+<dl>
-<p> Unlike other Postfix databases such as "hash" or "btree", you
-can't rebuild a corrupted LMDB database simply by running <a href="postmap.1.html">postmap(1)</a>
-or <a href="postalias.1.html">postalias(1)</a>, as those commands will crash, too. </p>
-
-<p> The reason for this limitation is that the Postfix LMDB database
-client does not implement the database "truncate" operation. Instead
-it tries to save all store requests to a transaction for later
-processing. That is obviously not possible with a corrupted database
-file. </p>
-
-<p> To recover, you must first delete the ".lmdb" file by hand, and
-only then you can retry the <a href="postmap.1.html">postmap(1)</a> or <a href="postalias.1.html">postalias(1)</a> command.
-</p>
-
-<li> <p> <strong>Incompatibility with <a href="tlsmgr.8.html">tlsmgr(8)</a>. </strong></p>
-
-<p> The Postfix LMDB database client breaks <a href="tlsmgr.8.html">tlsmgr(8)</a> TLS session
-cache management. Specifically, it breaks how <a href="tlsmgr.8.html">tlsmgr(8)</a> clears its
-TLS session cache databases upon start-up, it breaks how <a href="tlsmgr.8.html">tlsmgr(8)</a>
-looks up new TLS session cache entries, and it breaks how <a href="tlsmgr.8.html">tlsmgr(8)</a>
-automatically recovers from a corrupted database file. <p>
-
-<p> The reason for these limitations is that the Postfix LMDB
-database client does not implement the database "truncate" operation.
-Instead it saves all store requests to a transaction which it commits
-only when the database is closed. Therefore, <a href="tlsmgr.8.html">tlsmgr(8)</a> will never
-find any entries that it stores after opening its TLS session cache
-databases. And when the database becomes corrupted, <a href="tlsmgr.8.html">tlsmgr(8)</a> will
-keep crashing until someone removes the file ".lmdb" file by hand.
-</p>
+<dt> Problem: </dt> <dd> <p> "database full" errors with daemon
+programs such as <a href="postscreen.8.html">postscreen(8)</a>, <a href="tlsmgr.8.html">tlsmgr(8)</a> or <a href="verify.8.html">verify(8)</a>. This problem
+does not exist with other Postfix databases. </p> </dd>
-</ul>
+<dt> Impact: </dt> <dd> <p> Postfix does not process mail until
+someone fixes the problem. </p> </dd>
+
+<dt> Recovery: </dt> <dd> <p> Increase the <a href="postconf.5.html#lmdb_map_size">lmdb_map_size</a> limit in
+<a href="postconf.5.html">main.cf</a>, and "reload" Postfix. </p> </dd>
+
+</dl>
+
+<p> <strong>Non-obvious recovery with <a href="postmap.1.html">postmap(1)</a>/<a href="postalias.1.html">postalias(1)</a>
+from a corrupted database. </strong></p>
+
+<dl>
+
+<dt> Problem: </dt> <dd> <p> You cannot rebuild a corrupted LMDB
+database simply by running <a href="postmap.1.html">postmap(1)</a> or <a href="postalias.1.html">postalias(1)</a>. This problem
+does not exist with other Postfix databases. </p> </dd>
+
+<dt> Background: </dt> <dd> <p> The reason for this limitation is
+that the Postfix LMDB database client does not truncate the database
+file. Instead it attempts to save the "drop" request and subsequent
+"store" requests to a transaction for later processing. That is
+obviously not possible with a corrupted database file. </p> </dd>
+
+<dt> Recovery: </dt> <dd> <p> First delete the ".lmdb" file by hand,
+then rebuild the file with the <a href="postmap.1.html">postmap(1)</a> or <a href="postalias.1.html">postalias(1)</a> command.
+</p> </dd>
+
+</dl>
+
+<p> <strong>Incompatibility with <a href="tlsmgr.8.html">tlsmgr(8)</a>. </strong></p>
+
+<dl>
+
+<dt> Problem: </dt> <dd> <p> The Postfix LMDB database client never
+commits any <a href="tlsmgr.8.html">tlsmgr(8)</a> transaction. This problem does not exist with
+other Postfix databases. </p> </dd>
+
+<dt> Background: </dt> <dd> <p> Instead, it creates a single
+transaction that accumulates a "drop" request and all <a href="tlsmgr.8.html">tlsmgr(8)</a>
+"store" requests that are made during the lifetime of the process.
+</p> </dd>
+
+<dt> Solution: </dt> <dd> <p> This requires changes to the Postfix
+dictionary API, or to the Postfix LMDB database client. </p> </dd>
+
+<dt> Problem: </dt> <dd> <p> The Postfix LMDB database client breaks
+how <a href="tlsmgr.8.html">tlsmgr(8)</a> automatically recovers from a corrupted database file.
+This problem does not exist with other Postfix databases. <p> </dd>
+
+<dt> Background: </dt> <dd> <p> The Postfix LMDB database client
+does not truncate the database file. Instead it attempts to create
+a transaction which obviously is not possible when the database
+file is corrupted. </p> </dd>
+
+<dt> Impact: </dt> <dd> <p> The <a href="tlsmgr.8.html">tlsmgr(8)</a> process will keep crashing
+until someone removes the ".lmdb" file. </p> </dd>
+
+<dt> Recovery: </dt> <dd> <p> Remove the the ".lmdb" file by hand,
+and wait until the <a href="tlsmgr.8.html">tlsmgr(8)</a> process restarts. </p> </dd>
+
+</dl>
</body>
<li> <a href="LDAP_README.html"> LDAP Howto </a>
+<li> <a href="LMDB_README.html"> LMDB Howto </a>
+
<li> <a href="MEMCACHE_README.html"> Memcache Howto </a>
<li> <a href="MYSQL_README.html"> MySQL Howto </a>
</ol>
-<blockquote> <p> Caution: the current Postfix LMDB client has <a
-href="#limitations">unexpected limitations</a>. For this reason,
-LMDB support is not part of the stable Postfix release. </p>
-</blockquote>
+<dl> <dt> Caution: </dt> <dd> <p> The current Postfix LMDB client
+has <a href="#limitations">unexpected limitations</a> that don't
+exist with other Postfix databases. For this reason, LMDB support
+will not be part of the stable Postfix release without further
+changes to the Postfix LMDB client or the Postfix dictionary API.
+</p> </dd> </dl>
<h2><a name="with_lmdb">Building Postfix with OpenLDAP LMDB support</a></h2>
More information is available at
http://highlandsun.com/hyc/mdb/. </p>
-<h2><a name="limitations">Limitations of Postfix LMDB databases. </a> </h2>
-
-<ul>
+<h2><a name="limitations">Limitations of Postfix LMDB databases.
+</a> </h2>
-<li> <p> <strong>Unexpected postmap/postalias "database full" errors.
+<p> <strong>Unexpected postmap(1)/postalias(1) "database full" errors.
</strong></p>
-<p> Even if the "postmap filename" command succeeds, the exact same
-command, with the exact same input data, may fail subsequently with
-an MDB_MAP_FULL error. The reason is that unlike other Postfix
-databases such as "hash" or "btree", </p>
+<dl>
-<ul>
+<dt> Problem: </dt> <dd> <p> Even if the "postmap lmdb:filename"
+command succeeds, the exact same command (with the exact same input
+data) may fail subsequently with an MDB_MAP_FULL error. This problem
+does not exist with other Postfix databases. </p> </dd>
-<li> <p> LMDB databases have a hard size limit (configured with the
+<dt> Background: </dt>
+
+<dd>
+
+<p> LMDB databases have a hard size limit (configured with the
lmdb_map_size configuration parameter). </p>
-<li> <p> The Postfix LMDB database client does not implement the
-"truncate" operation. Instead it saves all store requests to a
-transaction (which takes up space in addition to the existing data),
-and commits the transaction when the database is closed. Only then
-can the space for old data be reused. </p>
+<p> When executing "postmap lmdb:filename", the Postfix LMDB database
+client does not truncate the database file. Instead it saves the
+"drop" request and subsequent "store" requests to a transaction
+(which takes up space in addition to the existing data), and commits
+the transaction when it closes the database. Only then can the
+space for old data be reused. </p>
-</ul>
+</dd>
-<p> This postmap(1) or postalias(1) command failure does not affect
-Postfix availability, because the old data still exists in the
-database. </p>
+<dt> Impact: </dt> <dd> <p> This failure does not affect Postfix
+availability, because the old data still exists in the database.
+</p> </dd>
-<p> To recover, increase the lmdb_map_size limit in main.cf, and
-retry the postmap(1) or postalias(1) command. </p>
+<dt> Recovery: </dt> <dd> <p> Increase the lmdb_map_size limit in
+main.cf, and retry the postmap(1) or postalias(1) command. </p>
+</dd>
-<li> <p> <strong>Postfix daemon "database full" errors. </strong></p>
+</dl>
-<p> Unfortunately, "database full" problems will affect Postfix
-availability with daemon programs such as postscreen(8), tlsmgr(8)
-or verify(8). These daemon programs will continue to fail until
-someone increases the lmdb_map_size parameter value. Meanwhile,
-mail processing comes to a halt. </p>
+<p> <strong>Postfix daemon "database full" errors. </strong></p>
-<li> <p> <strong>Non-obvious recovery from a corrupted database.
-</strong></p>
+<dl>
-<p> Unlike other Postfix databases such as "hash" or "btree", you
-can't rebuild a corrupted LMDB database simply by running postmap(1)
-or postalias(1), as those commands will crash, too. </p>
-
-<p> The reason for this limitation is that the Postfix LMDB database
-client does not implement the database "truncate" operation. Instead
-it tries to save all store requests to a transaction for later
-processing. That is obviously not possible with a corrupted database
-file. </p>
-
-<p> To recover, you must first delete the ".lmdb" file by hand, and
-only then you can retry the postmap(1) or postalias(1) command.
-</p>
-
-<li> <p> <strong>Incompatibility with tlsmgr(8). </strong></p>
-
-<p> The Postfix LMDB database client breaks tlsmgr(8) TLS session
-cache management. Specifically, it breaks how tlsmgr(8) clears its
-TLS session cache databases upon start-up, it breaks how tlsmgr(8)
-looks up new TLS session cache entries, and it breaks how tlsmgr(8)
-automatically recovers from a corrupted database file. <p>
-
-<p> The reason for these limitations is that the Postfix LMDB
-database client does not implement the database "truncate" operation.
-Instead it saves all store requests to a transaction which it commits
-only when the database is closed. Therefore, tlsmgr(8) will never
-find any entries that it stores after opening its TLS session cache
-databases. And when the database becomes corrupted, tlsmgr(8) will
-keep crashing until someone removes the file ".lmdb" file by hand.
-</p>
+<dt> Problem: </dt> <dd> <p> "database full" errors with daemon
+programs such as postscreen(8), tlsmgr(8) or verify(8). This problem
+does not exist with other Postfix databases. </p> </dd>
-</ul>
+<dt> Impact: </dt> <dd> <p> Postfix does not process mail until
+someone fixes the problem. </p> </dd>
+
+<dt> Recovery: </dt> <dd> <p> Increase the lmdb_map_size limit in
+main.cf, and "reload" Postfix. </p> </dd>
+
+</dl>
+
+<p> <strong>Non-obvious recovery with postmap(1)/postalias(1)
+from a corrupted database. </strong></p>
+
+<dl>
+
+<dt> Problem: </dt> <dd> <p> You cannot rebuild a corrupted LMDB
+database simply by running postmap(1) or postalias(1). This problem
+does not exist with other Postfix databases. </p> </dd>
+
+<dt> Background: </dt> <dd> <p> The reason for this limitation is
+that the Postfix LMDB database client does not truncate the database
+file. Instead it attempts to save the "drop" request and subsequent
+"store" requests to a transaction for later processing. That is
+obviously not possible with a corrupted database file. </p> </dd>
+
+<dt> Recovery: </dt> <dd> <p> First delete the ".lmdb" file by hand,
+then rebuild the file with the postmap(1) or postalias(1) command.
+</p> </dd>
+
+</dl>
+
+<p> <strong>Incompatibility with tlsmgr(8). </strong></p>
+
+<dl>
+
+<dt> Problem: </dt> <dd> <p> The Postfix LMDB database client never
+commits any tlsmgr(8) transaction. This problem does not exist with
+other Postfix databases. </p> </dd>
+
+<dt> Background: </dt> <dd> <p> Instead, it creates a single
+transaction that accumulates a "drop" request and all tlsmgr(8)
+"store" requests that are made during the lifetime of the process.
+</p> </dd>
+
+<dt> Solution: </dt> <dd> <p> This requires changes to the Postfix
+dictionary API, or to the Postfix LMDB database client. </p> </dd>
+
+<dt> Problem: </dt> <dd> <p> The Postfix LMDB database client breaks
+how tlsmgr(8) automatically recovers from a corrupted database file.
+This problem does not exist with other Postfix databases. <p> </dd>
+
+<dt> Background: </dt> <dd> <p> The Postfix LMDB database client
+does not truncate the database file. Instead it attempts to create
+a transaction which obviously is not possible when the database
+file is corrupted. </p> </dd>
+
+<dt> Impact: </dt> <dd> <p> The tlsmgr(8) process will keep crashing
+until someone removes the ".lmdb" file. </p> </dd>
+
+<dt> Recovery: </dt> <dd> <p> Remove the the ".lmdb" file by hand,
+and wait until the tlsmgr(8) process restarts. </p> </dd>
+
+</dl>
</body>
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20130315"
+#define MAIL_RELEASE_DATE "20130316"
#define MAIL_VERSION_NUMBER "2.11"
#ifdef SNAPSHOT
projects / thirdparty / postfix.git / commitdiff
