mirror of
https://github.com/vdukhovni/postfix
synced 2025-08-22 09:57:34 +00:00
postfix-2.11-20130318
This commit is contained in:
Wietse Venema
Viktor Dukhovni
parent
c5d32fd76b
commit
8db6af2ac4
@ -18284,3 +18284,7 @@ Apologies for any names omitted.
|
||||
When a program opens an LMDB file larger than lmdb_map_size/3,
|
||||
it logs a warning and uses a larger size limit instead.
|
||||
Files: util/dict_lmdb.c, proto/LMDB_README.html.
|
||||
|
||||
20130318
|
||||
|
||||
Portability: botched #ifdef. File: util/dict_lmdb.c.
|
||||
|
||||
@ -75,7 +75,7 @@ MEMCACHE_TABLE(5) MEMCACHE_TABLE(5)
|
||||
Postfix instance that will be responsible for cache
|
||||
cleanup.
|
||||
|
||||
NOTE 2: When different tables share the same mem-
|
||||
NOTE 2: When multiple tables share the same mem-
|
||||
cache database, each table should use the <b>key_for-</b>
|
||||
<b>mat</b> feature (see below) to prepend its own unique
|
||||
string to the lookup key. Otherwise, automatic
|
||||
@ -112,18 +112,19 @@ MEMCACHE_TABLE(5) MEMCACHE_TABLE(5)
|
||||
|
||||
<b>MEMCACHE KEY PARAMETERS</b>
|
||||
<b>key_format (default: %s)</b>
|
||||
Format of the lookup and update keys in memcache
|
||||
requests. By default, these are the same as the
|
||||
lookup and update keys that are given to the Post-
|
||||
fix memcache client.
|
||||
Format of the lookup and update keys that the Post-
|
||||
fix memcache client sends to the memcache server.
|
||||
By default, these are the same as the lookup and
|
||||
update keys that the memcache client receives from
|
||||
Postfix applications.
|
||||
|
||||
NOTE 1: The <b>key_format</b> feature is not used for
|
||||
NOTE 1: The <b>key_format</b> feature is not used for
|
||||
<b>backup</b> database requests.
|
||||
|
||||
NOTE 2: When different tables share the same mem-
|
||||
cache database, each table should prepend its own
|
||||
unique string to the lookup key. Otherwise, auto-
|
||||
matic <a href="postscreen.8.html"><b>postscreen</b>(8)</a> or <a href="verify.8.html"><b>verify</b>(8)</a> cache cleanup may
|
||||
NOTE 2: When multiple tables share the same mem-
|
||||
cache database, each table should prepend its own
|
||||
unique string to the lookup key. Otherwise, auto-
|
||||
matic <a href="postscreen.8.html"><b>postscreen</b>(8)</a> or <a href="verify.8.html"><b>verify</b>(8)</a> cache cleanup may
|
||||
not work.
|
||||
|
||||
Examples:
|
||||
@ -137,48 +138,48 @@ MEMCACHE_TABLE(5) MEMCACHE_TABLE(5)
|
||||
|
||||
<b>%%</b> This is replaced by a literal '%' character.
|
||||
|
||||
<b>%s</b> This is replaced by the memcache client
|
||||
<b>%s</b> This is replaced by the memcache client
|
||||
input key.
|
||||
|
||||
<b>%u</b> When the input key is an address of the form
|
||||
user@domain, <b>%u</b> is replaced by the SQL
|
||||
quoted local part of the address. Other-
|
||||
wise, <b>%u</b> is replaced by the entire search
|
||||
quoted local part of the address. Other-
|
||||
wise, <b>%u</b> is replaced by the entire search
|
||||
string. If the localpart is empty, a lookup
|
||||
is silently suppressed and returns no
|
||||
results (an update is skipped with a warn-
|
||||
is silently suppressed and returns no
|
||||
results (an update is skipped with a warn-
|
||||
ing).
|
||||
|
||||
<b>%d</b> When the input key is an address of the form
|
||||
user@domain, <b>%d</b> is replaced by the domain
|
||||
user@domain, <b>%d</b> is replaced by the domain
|
||||
part of the address. Otherwise, a lookup is
|
||||
silently suppressed and returns no results
|
||||
silently suppressed and returns no results
|
||||
(an update is skipped with a warning).
|
||||
|
||||
<b>%[SUD]</b> The upper-case equivalents of the above
|
||||
expansions behave in the <b>key_format</b> parame-
|
||||
expansions behave in the <b>key_format</b> parame-
|
||||
ter identically to their lower-case counter-
|
||||
parts.
|
||||
|
||||
<b>%[1-9]</b> The patterns %1, %2, ... %9 are replaced by
|
||||
<b>%[1-9]</b> The patterns %1, %2, ... %9 are replaced by
|
||||
the corresponding most significant component
|
||||
of the input key's domain. If the input key
|
||||
of the input key's domain. If the input key
|
||||
is <i>user@mail.example.com</i>, then %1 is <b>com</b>, %2
|
||||
is <b>example</b> and %3 is <b>mail</b>. If the input key
|
||||
is <b>example</b> and %3 is <b>mail</b>. If the input key
|
||||
is unqualified or does not have enough
|
||||
domain components to satisfy all the speci-
|
||||
fied patterns, a lookup is silently sup-
|
||||
domain components to satisfy all the speci-
|
||||
fied patterns, a lookup is silently sup-
|
||||
pressed and returns no results (an update is
|
||||
skipped with a warning).
|
||||
|
||||
<b>domain (default: no domain list)</b>
|
||||
This feature can significantly reduce database
|
||||
server load. Specify a list of domain names, paths
|
||||
to files, or "<a href="DATABASE_README.html">type:table</a>" databases. When speci-
|
||||
to files, or "<a href="DATABASE_README.html">type:table</a>" databases. When speci-
|
||||
fied, only fully qualified search keys with a *non-
|
||||
empty* localpart and a matching domain are eligible
|
||||
for lookup or update: bare 'user' lookups, bare
|
||||
domain lookups and "@domain" lookups are silently
|
||||
for lookup or update: bare 'user' lookups, bare
|
||||
domain lookups and "@domain" lookups are silently
|
||||
skipped (updates are skipped with a warning).
|
||||
Example:
|
||||
|
||||
@ -192,33 +193,33 @@ MEMCACHE_TABLE(5) MEMCACHE_TABLE(5)
|
||||
The maximal memcache reply line length in bytes.
|
||||
|
||||
<b>max_try (default: 2)</b>
|
||||
The number of times to try a memcache command
|
||||
before giving up. The memcache client does not
|
||||
The number of times to try a memcache command
|
||||
before giving up. The memcache client does not
|
||||
retry a command when the memcache server accepts no
|
||||
connection.
|
||||
|
||||
<b>retry_pause (default: 1)</b>
|
||||
The time in seconds before retrying a failed mem-
|
||||
The time in seconds before retrying a failed mem-
|
||||
cache command.
|
||||
|
||||
<b>timeout (default: 2)</b>
|
||||
The time limit for sending a memcache command and
|
||||
The time limit for sending a memcache command and
|
||||
for receiving a memcache reply.
|
||||
|
||||
<b>BUGS</b>
|
||||
The Postfix memcache client cannot be used for security-
|
||||
sensitive tables such as <b><a href="postconf.5.html#alias_maps">alias_maps</a></b> (these may contain
|
||||
"<i>|command</i> and "<i>/file/name</i>" destinations), or <b><a href="postconf.5.html#virtual_uid_maps">vir</a>-</b>
|
||||
<b><a href="postconf.5.html#virtual_uid_maps">tual_uid_maps</a></b>, <b><a href="postconf.5.html#virtual_gid_maps">virtual_gid_maps</a></b> and <b><a href="postconf.5.html#virtual_mailbox_maps">virtual_mailbox_maps</a></b>
|
||||
(these specify UNIX process privileges or "<i>/file/name</i>"
|
||||
destinations). In a typical deployment a memcache data-
|
||||
base is writable by any process that can talk to the mem-
|
||||
cache server; in contrast, security-sensitive tables must
|
||||
The Postfix memcache client cannot be used for security-
|
||||
sensitive tables such as <b><a href="postconf.5.html#alias_maps">alias_maps</a></b> (these may contain
|
||||
"<i>|command</i> and "<i>/file/name</i>" destinations), or <b><a href="postconf.5.html#virtual_uid_maps">vir</a>-</b>
|
||||
<b><a href="postconf.5.html#virtual_uid_maps">tual_uid_maps</a></b>, <b><a href="postconf.5.html#virtual_gid_maps">virtual_gid_maps</a></b> and <b><a href="postconf.5.html#virtual_mailbox_maps">virtual_mailbox_maps</a></b>
|
||||
(these specify UNIX process privileges or "<i>/file/name</i>"
|
||||
destinations). In a typical deployment a memcache data-
|
||||
base is writable by any process that can talk to the mem-
|
||||
cache server; in contrast, security-sensitive tables must
|
||||
never be writable by the unprivileged Postfix user.
|
||||
|
||||
The Postfix memcache client requires additional configura-
|
||||
tion when used as <a href="postscreen.8.html"><b>postscreen</b>(8)</a> or <a href="verify.8.html"><b>verify</b>(8)</a> cache. For
|
||||
details see the <b>backup</b> and <b>ttl</b> parameter discussions in
|
||||
tion when used as <a href="postscreen.8.html"><b>postscreen</b>(8)</a> or <a href="verify.8.html"><b>verify</b>(8)</a> cache. For
|
||||
details see the <b>backup</b> and <b>ttl</b> parameter discussions in
|
||||
the MEMCACHE MAIN PARAMETERS section above.
|
||||
|
||||
<b>SEE ALSO</b>
|
||||
@ -230,11 +231,11 @@ MEMCACHE_TABLE(5) MEMCACHE_TABLE(5)
|
||||
<a href="MEMCACHE_README.html">MEMCACHE_README</a>, Postfix memcache client guide
|
||||
|
||||
<b>LICENSE</b>
|
||||
The Secure Mailer license must be distributed with this
|
||||
The Secure Mailer license must be distributed with this
|
||||
software.
|
||||
|
||||
<b>HISTORY</b>
|
||||
Memcache support was introduced with Postfix version 2.9.
|
||||
Memcache support was introduced with Postfix version 2.9.
|
||||
|
||||
<b>AUTHOR(S)</b>
|
||||
Wietse Venema
|
||||
|
||||
@ -79,7 +79,7 @@ NOTE 1: When sharing a persistent \fBpostscreen\fR(8) or
|
||||
*_cache_cleanup_interval = 0) except with one Postfix
|
||||
instance that will be responsible for cache cleanup.
|
||||
|
||||
NOTE 2: When different tables share the same memcache
|
||||
NOTE 2: When multiple tables share the same memcache
|
||||
database, each table should use the \fBkey_format\fR feature
|
||||
(see below) to prepend its own unique string to the lookup
|
||||
key. Otherwise, automatic \fBpostscreen\fR(8) or \fBverify\fR(8)
|
||||
@ -113,14 +113,16 @@ time. Smaller values are relative to the time of the update.
|
||||
.ad
|
||||
.fi
|
||||
.IP "\fBkey_format (default: %s)\fB"
|
||||
Format of the lookup and update keys in memcache requests.
|
||||
Format of the lookup and update keys that the Postfix
|
||||
memcache client sends to the memcache server.
|
||||
By default, these are the same as the lookup and update
|
||||
keys that are given to the Postfix memcache client.
|
||||
keys that the memcache client receives from Postfix
|
||||
applications.
|
||||
|
||||
NOTE 1: The \fBkey_format\fR feature is not used for \fBbackup\fR
|
||||
database requests.
|
||||
|
||||
NOTE 2: When different tables share the same memcache
|
||||
NOTE 2: When multiple tables share the same memcache
|
||||
database, each table should prepend its own unique string
|
||||
to the lookup key. Otherwise, automatic \fBpostscreen\fR(8)
|
||||
or \fBverify\fR(8) cache cleanup may not work.
|
||||
|
||||
@ -71,7 +71,7 @@
|
||||
# *_cache_cleanup_interval = 0) except with one Postfix
|
||||
# instance that will be responsible for cache cleanup.
|
||||
#
|
||||
# NOTE 2: When different tables share the same memcache
|
||||
# NOTE 2: When multiple tables share the same memcache
|
||||
# database, each table should use the \fBkey_format\fR feature
|
||||
# (see below) to prepend its own unique string to the lookup
|
||||
# key. Otherwise, automatic \fBpostscreen\fR(8) or \fBverify\fR(8)
|
||||
@ -103,14 +103,16 @@
|
||||
# .ad
|
||||
# .fi
|
||||
# .IP "\fBkey_format (default: %s)\fB"
|
||||
# Format of the lookup and update keys in memcache requests.
|
||||
# Format of the lookup and update keys that the Postfix
|
||||
# memcache client sends to the memcache server.
|
||||
# By default, these are the same as the lookup and update
|
||||
# keys that are given to the Postfix memcache client.
|
||||
# keys that the memcache client receives from Postfix
|
||||
# applications.
|
||||
#
|
||||
# NOTE 1: The \fBkey_format\fR feature is not used for \fBbackup\fR
|
||||
# database requests.
|
||||
#
|
||||
# NOTE 2: When different tables share the same memcache
|
||||
# NOTE 2: When multiple tables share the same memcache
|
||||
# database, each table should prepend its own unique string
|
||||
# to the lookup key. Otherwise, automatic \fBpostscreen\fR(8)
|
||||
# or \fBverify\fR(8) cache cleanup may not work.
|
||||
|
||||
@ -20,7 +20,7 @@
|
||||
* Patches change both the patchlevel and the release date. Snapshots have no
|
||||
* patchlevel; they change the release date only.
|
||||
*/
|
||||
#define MAIL_RELEASE_DATE "20130317"
|
||||
#define MAIL_RELEASE_DATE "20130318"
|
||||
#define MAIL_VERSION_NUMBER "2.11"
|
||||
|
||||
#ifdef SNAPSHOT
|
||||
|
||||
@ -471,21 +471,29 @@ DICT *dict_lmdb_open(const char *path, int open_flags, int dict_flags)
|
||||
msg_fatal("env_create %s: %s", mdb_path, mdb_strerror(status));
|
||||
|
||||
/*
|
||||
* For continued availability, try to ensure that the LMDB size limit is
|
||||
* at least 3x the current LMDB file size. This should be sufficient for
|
||||
* short-lived Postfix daemon processes.
|
||||
* Try to ensure that the LMDB size limit is at least 3x the current LMDB
|
||||
* file size. This should be sufficient to ensure that short-lived
|
||||
* Postfix daemon processes can recover from a "table full" error.
|
||||
*
|
||||
* Note: readers must increase their LMDB size limit, too, otherwise they
|
||||
* won't be able to continue reading a table after grows.
|
||||
*/
|
||||
#ifdef SIZE_T_MAX
|
||||
#ifndef SIZE_T_MAX
|
||||
#define SIZE_T_MAX __MAXINT__(size_t)
|
||||
#endif
|
||||
#define LMDB_SIZE_FUDGE_FACTOR 3
|
||||
|
||||
if (stat(mdb_path, &st) == 0 && st.st_size >= dict_lmdb_map_size / 2) {
|
||||
msg_warn("%s: file size %lu >= (%s map size limit %ld)/3 -- "
|
||||
if (stat(mdb_path, &st) == 0
|
||||
&& st.st_size >= dict_lmdb_map_size / LMDB_SIZE_FUDGE_FACTOR) {
|
||||
msg_warn("%s: file size %lu >= (%s map size limit %ld)/%d -- "
|
||||
"using a larger map size limit",
|
||||
mdb_path, (unsigned long) st.st_size,
|
||||
DICT_TYPE_LMDB, (long) dict_lmdb_map_size);
|
||||
dict_lmdb_map_size = 3 * st.st_size;
|
||||
if (dict_lmdb_map_size / 3 != st.st_size)
|
||||
DICT_TYPE_LMDB, (long) dict_lmdb_map_size,
|
||||
LMDB_SIZE_FUDGE_FACTOR);
|
||||
/* Defense against naive optimizers. */
|
||||
if (st.st_size < SIZE_T_MAX / LMDB_SIZE_FUDGE_FACTOR)
|
||||
dict_lmdb_map_size = st.st_size * LMDB_SIZE_FUDGE_FACTOR;
|
||||
else
|
||||
dict_lmdb_map_size = SIZE_T_MAX;
|
||||
}
|
||||
if ((status = mdb_env_set_mapsize(env, dict_lmdb_map_size)))
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user