Ralf Hildebrandt wrote:
>
> On Fri, Nov 02, 2001 at 08:14:32PM +0300, Michael Tokarev wrote:
[]
> > Wow, interesting point: qmgr can benefit from having "self-reloading"
> > maps, i.e. for some map types like e.g. berkeley db3, there is no need
> > to reload it after a modification. Also, for non-chrooted process, it
> > can just reopen a map after a change -- for qmgr on large sites it may
> > be very useful. A time for "map reload jumbo patch"? ;)
>
> I think this idea will be scrapped because of the fact that not all map
> types support this: Principle of least surprise.
>
> OTOH one might argue that some maps types are just "better" (depending on
> your definition of better) than others.

For qmgr, most benefit will be from the ability to *reopen* a map in
case it runs non-chrooted. I.e. instead of restarting, only reopen
is really needed -- when it can be done. For qmgr, loosing it's
internal in-memory state on restart can be bad.

In fact, there are two issues here: one is ability to skip reloading
of some "good" maps (some care definitely should be taken here anyway,
like e.g. forced reload if link count becomes e.g. 0 -- file deleted),
and second is the ability to reopen a map instead of a restart for
non-chrooted daemons. Both can be useful.

But I don't know if it's worth the effort -- how many *big* sites will
benefit from this (small sites will not, restart of a daemon isn't that
bad there). Note that transparent map reopening can trigger some
surprizing bugs in code (e.g. saved reference to dict_lookup result that
will become dangling after a reopen).

Regards,
 Michael.
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]