Victor Duchovni:
> On Mon, Jun 08, 2009 at 12:50:09PM -0400, Wietse Venema wrote:
>
> > Lebesgue Yu:
> > > Hi:
> > > ? ?As the subject says, I configure the postfix with the wrong smtp
> > > transport and try to send a email with that transport using command as
> > > following:
> > > ? ?postsuper -H ALL; postfix flush; sleep 1; postsuper -h ALL;
> >
> > Don't do this. It triggers a bug with the "new" queue manager where
> > it loses a hash table entry when it opens a queue file that it
> > has already opened:
> >
> > static QMGR_JOB *qmgr_job_create(QMGR_MESSAGE *message, QMGR_TRANSPORT
> > *transpor
> > t)
> > {
> > QMGR_JOB *job;
> >
> > job = (QMGR_JOB *) mymalloc(sizeof(QMGR_JOB));
> > job->message = message;
> > QMGR_LIST_APPEND(message->job_list, job, message_peers);
> > htable_enter(transport->job_byname, message->queue_id, (char *) job);
> >
> > To avoid a memory leak, the htable_enter() call should be guarded
> > with an htable_find() call, and if the entry already exists, then
> > the guard should defer the queue file.
>
> THere is such a guard:
>
> if ((job = qmgr_job_find(message, transport)) == 0)
> job = qmgr_job_create(message, transport);
>
> but, now the second copy of the message has the same "job" object as
> the first, ... The real problem is the mapping of message -> job, via a
> global queue-id -> job hash in the transport, rather than a per-message
> hash table indexed by transport name:
>
> /* qmgr_job_find - lookup job associated with named message and transport
> */
>
> /*
> * Instead of traversing the message job list, we use single per
> * transport hash table. This is better (at least with respect to memory
> * usage) than having single hash table (usually almost empty) for each
> * message.
> */
> return ((QMGR_JOB *) htable_find(transport->job_byname,
> message->queue_id));
Which makes it tempting to work around the collision by tweaking
the index that is used for job lookup. For example, use binhash(3)
with the memory address of the message data structure as index.
That might be an option for past releases.
For new releases, it makes sense to use a global hash of queue IDs.
I was already contemplating that in the wislist, so that I could
see if performance improves by eliminating the on-disk active queue.
Wietse
Wietse
