Robert,
First of all let me thank you for testing this feature :-)
Robert Voje wrote:
On Tue, 2005-04-05 at 16:40 -0600, Jesse Norell wrote:
So it's more a question of what is the practical limit dbmail should use
for cached headers (and it simply doesn't cache values if above that limit).
Yes it does:
dbmail/lmtpd[29839]: dbpgsql.c, db_query: Error executing query [INSERT
INTO dbmail_headervalue (headername_id, physmessage_id, headervalue)
VALUES (23,3612,'a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
h=received:message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole;
b=NHvYPHzaPDu3ThkTc+qw5jYjbCcWnHojOqH8/HTNzMW+E7ZOHX1Itrn3LfiL3veTN4t/BlPG1KqoERtakpttrt5SOglQ/1plGcP6cF+Ud5ehhrYGtywP0LBG3toxCj/+LuapwPd8e/7TKsokyl3Vx3X8iEuQANROV/NQQMynfU0=')]
Damn, this almost looks like a python pickle... What *are* they doing here I
wonder...
: [ERROR: value too long for type character varying(255) ]
Yep. I've been hitting that one as well while testing postgres. And how did you
adjust the field width in postgres?? Being a mysql user mostly myself, I'm so
used to using 'ALTER TABLE <table> CHANGE <fieldname> <field definition>' but
that don't work in postgres...
Right, I was meaning the right thing to do would be to not cache values
above that size (although depending on how the header cache ends up being
used, the right thing may be to either add a flag for being oversized and/
or just cache the first X bytes).
Sorry, I guess I misunderstood your answer.. :o
Beeing an SQL addict I prefer to store as much as possible in a
database. My preferred way would be the oversize-flag method.
maybe dbmail could read the max size of the field on startup and
clip the text to [max fieldsize] characters. (wishful thinking)
Mmm, perhaps I should get the field-width from the database schema, and clip the
headervalue accordingly. That way administrators can adjust this by changing the
database schema.
Anyway, if the cached header values are not a critical part of the
mail storage (not used by dbmail in any way)
Oh, but they will be once I've ironed out all the issues in the delivery chain
regarding this feature.
, then they could
be inserted in a separate transaction with only a warning if
something goes wrong..
Separate transaction. Definitely. I'll fix that.
Another effect of this was that neither the original recepient or
the mail sender received any clear notice of the error,
just a "null-recipient" error that was hard to understand.
I had to search the logs to find it, and with 20-30 spams rushing
in each minute that's always an unpleasant thing to do.
Isolating header caching in a separate transaction should do the trick. Header
caching or failure thereof should never cause malfunction in delivery. In fact
delivery should work even without the header tables.
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
